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Abstract 


NASA’s space data-communications infrastructure — the Space Network and the Ground Network— provide scheduled (as 
well as some limited types of unscheduled) data-communications services to user spacecraft. The Space Network operates sev- 
eral orbiting geostationary platforms (the Tracking and Data Relay Satellite System (TDRSS)), each with its own service- 
delivery antennas onboard. The Ground Network operates service-delivery antennas at ground stations located around the 
world. Together, these networks enable data transfer between user spacecraft and their mission control centers on Earth. 
Scheduling data-communications events for spacecraft that use the NASA communications infrastructure — the relay satellites 
and the ground stations — can be accomplished today with software having an operational heritage dating from the 1980s or 
earlier. An implementation of the scheduling methods and algorithms disclosed herein will produce globally optimized sched- 
ules with not only optimized service delivery by the space data-communications infrastructure but also optimized satisfaction of 
all user requirements and prescribed constraints, including radio frequency interference (RFI) constraints. Evolutionary algo- 
rithms, a class of probabilistic strategies for searching large solution spaces, is the essential technology involved in this disclo- 
sure. Also disclosed are secondary methods and algorithms for optimizing the execution efficiency of the schedule-generation 
algorithms themselves. The scheduling methods and algorithms as presented are adaptable to accommodate the complexity of 
scheduling the civilian and/or military data-communications infrastructure within the expected range of future users and space- 
or ground-based service-delivery assets. Finally, the problem itself, and the methods and algorithms, are generalized and speci- 
fied formally. The generalized methods and algorithms are applicable to a very broad class of combinatorial- optimization prob- 
lems that encompasses, among many others, the problem of generating optimal space-data communications schedules. 

General Terms: Scheduling, Algorithm, Computing, Space 

Additional Key Words and Phrases: System specification, space-data communications, radio frequency interference mitiga- 
tion, combinatorial optimization, genetic algorithm, evolutionary programming, probabilistic search, data regression 
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1.3 Incorporating RF Interference-Mitigation Constraints 


1 INTRODUCTION 


1. Introduction 

1.1. Background on NASA 
Data-Communications Scheduling 

Scheduling data-communications events for spacecraft that 
use the NASA communications infrastructure [25] — the re- 
lay satellites [18] and the ground stations [7] — can be ac- 
complished today with software having an operational her- 
itage dating from the 1980s or earlier [10, 30] with empha- 
sis on incremental and reactive scheduling [21]. Present op- 
erational scheduling capabilities do not generate true opti- 
mized schedules for reasons that will be explained below, but 
can (when the option is invoked) generate schedules that are 
free of radio frequency interference (RFI) effects by block- 
ing out portions of the problem- solution space from consid- 
eration whenever those portions appear with any predicted 
RFI effects. Similarly, the current operational scheduling sys- 
tem prunes away portions of the solution space upon encoun- 
tering violations of the various other constraints that must be 
satisfied. This approach, which perforce ignores large por- 
tions of the solution space, necessarily means that schedule 
optimization cannot be an actual achievable objective of the 
current scheduling system. 

Present space data-communications schedulers have 
the capability of algorithmically generating sched- 
ules using techniques for representing and exploring 
the problem-solution space as either a graph or a tree of re- 
lated sub-solutions. A number of standard algorithms 
for searching a solution space represented as a graph or 
tree are available. These, in general, operate by eliminat- 
ing branches of the tree where constraint violations (e.g., un- 
acceptable levels of RFI) are found (although any “slash 
and bum” approach or any “branch and bound” tech- 
nique has the undesirable consequence that it incorpo- 
rates no mechanism by which to avoid discarding sections of 
the tree that represent solutions that are better than any oth- 
ers that can be found in the course of running the sched- 
uler). NASA’s present operational scheduling system, using 
such standard search methods, is capable of producing work- 
able schedules, albeit with certain significant concessions to 
the compute-intensive nature of the search (including cer- 
tain problem simplifications that themselves, even ignoring 
the performance of the search techniques, preclude the pos- 
sibility of true schedule optimization). 

1.2. Toward an Optimizing Scheduler 

Current space data-communications scheduling sys- 
tems, which lack a true schedule-optimization capability, 
leave open the possibility that new methods for search- 
ing the solution space might result in improved infrastruc- 


ture performance and overall schedule-quality improvement, 
bringing increased overall customer satisfaction. 

Disclosed and specified herein are methods and algo- 
rithms for an optimizing, constraint-satisfying, automated 
scheduling system that potentially could be implemented 
in NASA’s space-data-communications infrastructure. Con- 
ceived and developed in the early 1990s, this is the first 
known such system (i.e., methods and algorithms) that — 

1. is capable of true schedule optimization considering 
prescribed constraints such as mitigation of RF inter- 
ference, 

2. is specified rigorously, and 

3. is implementable with adequate performance. 

The system (the methods and algorithms taken together) ad- 
dresses (a) the issue of performance and efficiency of 
the communications infrastructure and (b) the impor- 
tant space-mission operations-planning problem of op- 
timizing data-communications schedules. The desired 
optimization not only would include minimizing radio fre- 
quency interference effects that can reduce achievable data 
rates for space missions, but also would include accommo- 
dating other prescribed constraints such as hours of operation 
of mission control centers and anticipated or planned re- 
source outages. 

1.3. Incorporating RF Interference-Mitigation 
Constraints 

Practically all of the major emitters that produce RFI ef- 
fects are known as to both location (or dynamic position 
in space) and signal characteristics (frequency, power, signal 
structure, polarization, etc.). There are many such sources of 
RFI: ground-based radars, radio and television transmitters, 
other spacecraft, and even cellular telephone service-provider 
towers and their customers, among other emitters. (Individ- 
ual cell phone users are each insignificant, but in the aggre- 
gate, they represent an RF noise “floor” that can be charac- 
terized, predicted, and mitigated in various ways.) 

Beyond interference mitigation techniques (e.g., spread- 
spectrum signal structures that are built into both the NASA 
data-communications infrastructure and a user spacecraft’s 
onboard hardware and software), various RFI-avoidance 
mechanisms can be invoked during the process of schedul- 
ing communications-service delivery to users. Some of 
these mechanisms do not lend themselves to automa- 
tion, while others are based on rules of thumb and problem 
simplifications that, in general, do not promise the best pos- 
sible schedules (in terms of optimizing user satisfaction 
and service delivery by the data-communications infras- 
tructure), even if automated. The former category (i.e., 


5 



1 .5 The Essential Technology Used in the Present Disclosure 


1 INTRODUCTION 


manual mechanisms) does not represent practical ap- 
proaches for NASA, but an automated mechanism in the 
latter category (the application of rules of thumb and prob- 
lem simplifications) has been used in NASA’s scheduling 
system at least since the operational date of the Space Net- 
work. The herein-disclosed algorithm represents a third 
category of techniques for RFI avoidance in schedule gen- 
eration: it poses no difficulty for automation, is not based 
on rules of thumb (but, instead, closed-form calcula- 
tions of interference effects), and supports schedule opti- 
mization. 

An optimizing scheduler that satisfies constraints on RF 
interference requires prior RF analysis of the factors in- 
volved in the delivery of data-communications services, 
including the RF environment in which the communica- 
tions occur as well as the user’s requirements and the spe- 
cific characteristics of the user spacecraft. In the early 
1990s, NASA’s Communications Link Analysis and Sim- 
ulation System (CLASS) [8] fielded an interference anal- 
ysis system [14] — the CLASS IAS. The CLASS software 
is able to produce all of the auxiliary data needed as in- 
put for the operation of an interference-mitigation scheduling 
system (see Section 3.1 for a representative list of these in- 
puts). 

1.4. Concerning Processes, Methods, and 
Algorithms 

Although it represents one of the most essential concepts 
in computer science, the term “algorithm”, perhaps surpris- 
ingly, has no generally accepted technical definition 1 . Fur- 
ther, definitions of “process” and “method” typically are non 
technical and imprecise. Trying to identify, with accuracy, 
distinctions between these three terms therefore would be ad- 
venturous. However, for the purposes of this paper, we see (at 
least minor) conceptual differences, and these differences are 
reflected in the way the terms are used herein. 

A process is “a series of actions or steps taken in order to 
achieve a particular end” 2 . 

A method, considered as a “process by which a task is 
completed; a way of doing something” 3 , entails a list of steps 
to be performed to accomplish an objective or intended re- 
sult. An algorithm, of course, also includes a list of steps to 
be performed. For the purposes of this paper, it is assumed 
that every algorithm, but not every method, can be performed 
mechanically, at least in principle. Consequently, every algo- 


1 Wikipedia article entitled “Algorithm” at http://www.wikipedia.org/ 
(accessed 18 October 2009). 

2 Oxford American Dictionaries accessed 28 October 2009. 

3 Wictionary entry at http://en.wiktionary.org/ (accessed 28 October 
2009). 


rithm, but not every method, must be specifiable with preci- 
sion sufficient to make it accurately implementable as a com- 
puter program. 

In this paper, we endeavor to adhere to the following 
scheme: a sequence of steps or actions is said to be a(n) — 

1. “Algorithm” when the steps are expected to be imple- 
mented in and performed by a computer application and 
the result of the completion of the sequence of steps is 
representable as a data structure 

2. “Method” when the goal of the sequence of steps is 
broad or high-level and a human must perform at least 
one of the steps 

3. “Process” when each of the steps is definite and pre- 
cisely specifiable, when a human must perform at least 
one of the steps, and when the result of performing each 
of the steps in the sequence is not necessarily repre- 
sentable as a data structure 

1.5. The Essential Technology Used in the 
Present Disclosure 

The algorithms and methods disclosed herein apply princi- 
ples from the computer-science field of evolutionary search 
and combinatorial optimization [2, 4, 9, 29] to solve the 
problem of finding an optimal overall schedule [24, 31] that 
(a) will satisfy user requirements for communications sup- 
port from NASA’s communications infrastructure and (b) 
will be consistent with NASA’s Space Network User’s Guide 
(SNUG) [18] as well as the operations guidelines for the 
Ground Network [7]. The quality of the schedules generated 
by a computer application program that implements this al- 
gorithm will be a monotonic function of the program’s ex- 
ecution time. During the search for better and better solu- 
tions, the best solutions found so far are retained and given a 
chance to influence the generation of new, possibly better so- 
lutions. When execution is terminated arbitrarily, the output 
will be the best solution found so far during the run, and the 
longer the run, the better the solution is expected to be. More 
will be said regarding the notion of optimization (see Sec- 
tion 2.4.7 (page 13)). 

In the remainder of this paper, any mention of “the dis- 
closed algorithm” will, depending on context, be understood 
to mean “the disclosed methods and algorithms”. 

1.6. Innovations Disclosed 

The present disclosure incorporates well-known technolo- 
gies, namely, genetic algorithms (evolutionary search) and 
data regression. The primary contributions disclosed herein 
are as follows: 
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1 . 8 Organization of Paper 


2 SPACE-DATA COMMUNICATIONS-SCHEDULING PROBLEM DEFINITION 


1. methods, algorithms, and processes for employ- 
ing evolutionary-search technologies in an optimizing 
scheduling system for the NASA space-data communi- 
cations infrastructure; 

2. a method and algorithm for optimizing the internal pa- 
rameters of a genetic algorithm (specifically the algo- 
rithms identified in item 1); and 

3. a method and algorithm for deriving a function that, 
given an arbitrary problem scenario in the problem do- 
main identified in item 1, will, in a cost-effective man- 
ner, return an estimate of the optimal values of the in- 
ternal parameters of a genetic algorithm for solving the 
given problem scenario. 

The author is not aware of any other disclosures equivalent 
to items 1, 2, or 3. 

Further, the methods and algorithms disclosed in Ap- 
pendix B (Section 11 (page 45)) generalize those in items 
1, 2, and 3 above and are applicable to a very broad class 
of problems. Many of the problems in this general class (re- 
ferred to as problems of Type G) pertain to NASA and the 
space program (e.g., the space data-communications schedul- 
ing problem treated in the main body of this paper, as well as 
space-mission design optimization and spacecraft-design op- 
timization), but numerous other fields (particularly those re- 
lated to design optimization, and, more broadly, virtually any 
field where solutions cannot be specified directly but can be 
evaluated as to “goodness”) are encompassed under the gen- 
eralized problem of Type G as defined in Appendix B. Fi- 
nally, the specifications of the methods and algorithms are 
sufficiently rigorous and detailed to facilitate not only the 
process of relating them to this broad class of real-world 
problems, but also the process of implementing them in a 
computer-application program. 

1.7. Audience for the Present Disclosure 

As indicated above, the main body of this paper concerns 
a particular application (NASA space-data communications 
scheduling), while Appendix B broadens the topic to en- 
compass a very broad range of application domains. The 
audience for the former would include groups responsible 
for designing and implementing space-data communications 
scheduling systems (or identifying appropriate technologies 
that could be used in such systems), while for the latter the 
audience would include practitioners generally and, espe- 
cially, groups designing and implementing any system for 
reaching optimal solutions for the generalized problem do- 
mains of Type G as defined in Appendix B. Any interest in 
this paper on the part of researchers and academics would 
likely be limited to the possible application, described herein. 


of well-known techniques from the field of evolutionary pro- 
gramming, and from the field of data-regression generally. 

1.8. Organization of Paper 

Section 2 describes the scheduling-problem domain in terms 
of the question of tractability and identifies a viable approach 
to searching for optimal solutions. Such an approach (to the 
author’s knowledge) has not been implemented or considered 
for use in NASA’s space-data communications infrastructure, 
which is the context (or, rather, the primary context) of the 
present disclosure. Section 3 presents the assumptions under- 
lying the specification of the disclosed algorithms. Section 4 
defines general domain terms and specific notations used in 
specifying the algorithm. The algorithm itself is precisely 
specified in Section 5. Section 6 presents an additional algo- 
rithm (also based on the principles of evolutionary search) for 
optimizing the search itself — producing the optimal choice 
of the values of the schedule-generation algorithm’s internal 
parameters. In a further abstraction of the overall space data- 
communications scheduling problem, Section 7 outlines ap- 
proaches for determining a function by which to estimate the 
optimal choice of the values of the schedule-generation al- 
gorithm’s internal parameters, given a scheduling scenario. 
The prototype implementation of the schedule-generation al- 
gorithm and the internal parameter optimization algorithm 
are briefly mentioned in Section S. Concluding remarks are 
given in Section 9. Section 1 0 (Appendix A) considers a pos- 
sible model to describe the performance of the schedule- 
generation algorithm, and describes a key insight afforded 
by analysis of the model. Finally, Section 1 1 (Appendix B) 
describes and specifies, in abstract terms, a broad class of 
problems — one member of which is the scheduling problem 
of the kind targeted by the methods and algorithms that are 
presented in the main body of this disclosure — and discloses 
and specifies generalized methods and algorithms for solv- 
ing problems in this general class. 

2. Space-Data 

Communications-Scheduling 
Problem Definition 

2.1. Space-Data Communications Scheduling 

2.1.1. Scheduling-System Objective. 

In the overall data-communications scheduling problem, the 
primary objective is to find a solution (i.e., a schedule) that 
maximizes delivery of services to users according to their re- 
quirements. 4 
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2.2 Size of the Solution Space 


2 SPACE-DATA COMMUNICATIONS-SCHEDULING PROBLEM DEFINITION 


The evaluation of candidate solutions will involve numer- 
ous factors that will be described in subsequent sections. In 
addition to various technical factors, the evaluation may also 
reflect NASA policy-level considerations such as the relative 
priority officially assigned to each spacecraft or mission. 

2.1.2. Primary Factors Affecting Achievability of 
Objective. 

Numerous factors bear on the achievability of the primary ob- 
jective. For example, all of the service-delivery assets in the 
data-communications infrastructure are subject to outages, 
both planned and unplanned. Planned outages result from 
equipment maintenance and upgrade activities. Unplanned 
outages are relatively rare and would include service in- 
terruptions due to severe weather or natural calamities like 
earthquakes. By definition, the process of searching for a so- 
lution of the overall scheduling problem does not incorporate 
unplanned outages. 

2.1.3. Technical Factors Affecting Achievability of 
Objective. 

Technical factors, as well, bear on the achievability of the 
primary objective. These factors include any phenomenon or 
circumstance that potentially could measurably degrade data- 
communications performance: 

1. radio frequency interference 

2. signal multipath interference 

3. signal-to-noise ratio reduction by noise due to space- 
craft charging 4 5 , antenna blockage, atmospheric effects, 
rocket plume effects, etc. 

The effects of all of these factors are dynamic, but they 
can be predicted through link analysis and simulation tech- 
niques [8, 14], given a user’s planned spacecraft orbit and at- 
titude profile to enable the determination of the effects listed 
above as items 2 and 3. Item 1 is determined by the num- 
ber and characteristics (including the orbital parameters and 
attitude profile) of all other spacecraft (not only US space- 
craft but also the spacecraft flown by other nations). The pre- 
dictability of the listed effects suggests that the process of 
searching the solution space could be made more efficient 


4 The possibility of requirements for cross communications (between user 
spacecraft, or between infrastructure assets) has not been overlooked 
and is not unimportant in the foreseeable future. Such requirements are 
beyond the scope of the present disclosure, but could be included in fu- 
ture adaptations of the methods and algorithms specified herein. 

5 John Kennewell and Andrew McDonald, “Satellite Communications 
and Space Weather”, Australian Government, Bureau of Meteorol- 
ogy, Ionospheric Prediction Service Radio and Space Services, Space 
Weather Agency web site, http://www.ips.gov.aU/Educational/l/3/2 (ac- 
cessed 20 August 2008). 


if all candidate schedules at least avoided communications 
events rendered useless by the above factors. This strategy, 
described in general terms in [24, 32] in relation to space- 
craft mutual interference, is an integral part of the algorithm 
disclosed herein and is applicable in general to all other pre- 
dictable phenomena and circumstances that potentially could 
measurably reduce data-communications performance. Fol- 
lowing this strategy, the herein-disclosed algorithm mitigates 
these effects automatically and produces optimal solutions 
of the overall scheduling problem. In the foregoing, the word 
“spacecraft” should be broadly interpreted to include user as- 
sets of other kinds (e.g., habitats or surface rovers). 

2.2. Size of the Solution Space 

2.2.1. Determining Factors. 

It is instructive to estimate, or at least establish a lower bound 
on, the size of the solution space for the data-communications 
scheduling problem for some simple combinations of users, 
user requirements, and service-delivery assets. Analysis of 
simple scheduling scenarios leads naturally to a better appre- 
ciation of how large might be the solution space for realis- 
tic scheduling scenarios. For any given scheduling scenario, 
the solution space comprises all possible schedules, each sat- 
isfying at least one requirement of at least one user. 

Each schedule consists of a set of communications events. 
Each event represents partial satisfaction of a user require- 
ment and is defined in terms of a number of parameters (most 
of which will not be discussed further herein): 

• start and end times for each forward link (when a NASA 
support antenna is radiating signals to the user asset) 

• start and end times for each return link (when the user 
asset is radiating signals to the NASA support antenna) 

• the frequency selection for each forward link 

• the frequency selection for each return link 

• the polarization of each forward link 

• the polarization of each return link 

• the data rate (or symbol rate) of each forward link 

• the data rate (or symbol rate) of each return link 

• pseudo-random-noise (PN) spread indicator for each 
forward link 

• pseudo-random-noise (PN) spread indicator for each re- 
turn link 

• NASA support-antenna selection for each forward link 

• NASA support-antenna selection for each return link 
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2.2.2. A Simple Example. 

The start and end times for a scheduled event have a one- 
second granularity and are represented as seconds of offset 
from some prescribed epoch (usually specified as a reference 
date such as 1 January 1970 that is “over the horizon” of past 
time in the current context). For a normal two-week schedul- 
ing period, there are 14 x 24 x 60 x 60 = 1, 209, 600 possible 
values for a start or end time. The event-duration minimum 
is nominally ten seconds and the duration maximum is nomi- 
nally 80 minutes. For a given start time, there would be 80 x 
60 — 10 = 4790 allowed intervals each representing a com- 
munications event at the given start time without violating the 
80-minute maximum limit or the 10-second minimum limit. 
If a schedule had only a single communications event with 
a single link for a given user during the two-week schedul- 
ing period, with no other constraints, there would be approx- 
imately 4790 x (1209600 - 4790/2) or 5.78 x 10 9 allowed 
instantiations of the event without violating the 80-minute 
maximum limit or the 10- second minimum limit. In a two- 
week scheduling period, with nominal duration of 90 minutes 
per orbit, there would be (14 x 24 x 60) /90 = 224 orbits. If 
in a two-week scheduling period, the given user required one 
single-link event in each orbit (see Figure 1), there would be 
224 events in the schedule. In each orbit, there would be ap- 
proximately 60 x (4790 x 10 + 4790 x 80/2) = 14, 370, 000 
possible events without violating the 80-minute maximum 
limit or the 10-second minimum limit. The number of pos- 
sible schedules — that is, the number of possible combina- 
tions of the possible events (with exactly one event in each 
of the 224 orbits) (ignoring other constraints) — would be ap- 
proximately (1.437 x 10 7 ) 224 . Thus, for this trivial schedul- 
ing scenario, the scheduling problem would have more than 
10 1603 possible solutions. Even if the maximum allowed du- 
ration of each event were reduced to 1 0 minutes, the cardinal- 
ity of the solution space would still exceed 10 145 °. For per- 
spective, consider this number in relation to the number of 
neutron-size spheres that could be packed into a sphere the 
size of the known universe — a number on the order of 10 135 . 


2.2.3. A More Realistic Example. 

The next factor bearing on the estimate of the size of the so- 
lution space for the TDRSS scheduling problem is the con- 
cept of the prototype event. A prototype event (to be defined 
more exactly in Subsection 4.3 (Definition 54 on page 20)) is, 
in general terms, a combination of data-communications link 
activations for actual forward and return data flows by which 
a user will accomplish various purposes, including forward 
links for delivering commands, data, and software loads to 
the spacecraft. Other purposes will pertain to returning data 
via return links to the mission control center or to scientists. 


orbit orbit 

start end 


0 10 20 30 40 50 60 70 80 90 minutes 


I I I I I I I I 


} 

} 


80-minute comm events 


shorter comm events 


Figure 1. Communications events placed rel- 
ative to the 90-minute-orbit time line, as al- 
lowed in the simple example scheduling sce- 
nario. Three possible maximum-duration com- 
munications events are shown, each with a dif- 
ferent start time offset from the start of the 
orbit. Three other possible communications 
events are shown with different allowed du- 
rations and start-time offsets. In the simple 
example scenario, the user requires only one 
communications event in the orbit. 


Each of the links is defined in terms of parameters that spec- 
ify data rate, frequency, polarization, support antenna, etc. 
The specification of the values of these parameters, along 
with the start and stop times in seconds of relative offset, and 
the allowed tolerance in these offsets, makes up the defini- 
tion of a prototype event. 

If, in a given scheduling-problem scenario, a prototype 
event has a required duration of 45 minutes and consists of 
five links, each with five allowed choices of NASA service- 
delivery antennas, and each with nominal duration of 10 min- 
utes, start-time tolerance of three minutes, and duration tol- 
erance of three minutes, then in comparison with the above 
example (a single spacecraft requiring one event per orbit), 
the size of the solution space (or its lower bound) would be- 
come a much larger number. This number is roughly calcu- 
lated by first calculating the number of possible instances 
of each prototype event that could be instantiated for any 
given prototype-event start time, and then calculating the 
number of possible instantiations of the prototype event in 
a given orbit. Allowing any start time that does not exceed 
45— (10+3) = 32 minutes of offset from the prototype-event 
start time, the number of possible instantiations of one of the 
links (ignoring the choices for service delivery antenna) is 
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60 x 32 x 60 x ((10 + 3) - (10 - 3)) = 691200. Allowing 
any start time offset between 32 minutes and 45 — (10 — 3) = 
38 minutes from the prototype-event start time, the num- 
ber of possible instantiations of one of the links (ignoring 
the choices for service-delivery antenna) is approximately 
60 x (38 - 32) x 60 x ((10 + 3) - (10 - 3))/2 = 64800. 
The minimum allowed duration of a link represents a con- 
straint to ensure that a link is not allowed to start with an 
offset of more than (in the present example) 38 minutes. 
Thus, for a given instantiation of the prototype event, the to- 
tal number of allowed instantiations of one of the links (ig- 
noring the choices for service-delivery antenna) would be 
691200 + 64800 = 756000. 

To simplify calculations and yet establish a lower bound 
on the number of possible instantiations of the given proto- 
type event, assume there is only one allowed start time for 
a prototype event in each orbit (although, typically, the al- 
lowed start time for a 45-minute prototype event would be 
any time in the first 45 minutes of the 90-minute orbit, so 
that there would be 2700 different allowed start times in 
each orbit). Then the number of possible instantiations of 
the prototype event per orbit — each instantiation being an al- 
lowed combination of five prototype-event links — would be 
756000 s = 2.469 x 10 29 . Therefore, the number of possi- 
ble combinations of prototype events in the 224 orbits in the 
scheduling period would exceed (10 29 ) 224 = 10 6496 . 

Thus, with consideration of all possible solutions allow- 
ing all possible combinations of prototype events for multi- 
ple users, with all possible combinations of allowed choices 
of data rate, frequency, polarization, support antennas, etc., it 
quickly becomes apparent that the solution space for a real- 
istic scheduling scenario would be much larger yet. 


2.2.4. Possible Approach to Reducing the Size of the 
Solution Space. 

A reduction of the size of the solution space could be real- 
ized by increasing the granularity of the allowed start times 
and durations for events. For example, one might allow only 
even-numbered seconds of offset from the prescribed epoch. 
At best, this would reduce the size of the solution space in the 
above simple example by a factor of (2 -5 ) 224 = 2 -1120 , or 
10 -337 , from 10 6496 to a number that yet still exceeds 10 6159 . 
Such an approach, if it results in a significant reduction in the 
size of the solution space, will not effect a tractable prob- 
lem without at the same time effectively eliminating the pos- 
sibility of finding optimal solutions. Making optimal solu- 
tions less likely (or impossible) to be found does not repre- 
sent an attractive characteristic of an approach for reducing 
the size of the solution space: enabling worse solutions to be 
found faster presents a dubious gain. 


Prototype event 


start end 


0 15 30 45 minutes 


-* 

-4 

-4 


TDRS-8 MA 
TDRS-5 SA2 
TDRS-8 SA1 
TDRS-5 SA1 
TDRS-5 MA 


Figure 2. An example prototype event for 
the more realistic example communications 
scheduling scenario. The user’s specification 
for a prototype event requires five links estab- 
lished and completed between the start time 
and end time of the prototype event. Each link 
has allowed tolerances on start time and du- 
ration, and has one of five allowed service- 
delivery antennas assigned to it (e.g., the 
TDRS-5 SA2 antenna). The user requires that 
an instance of the prototype event is to be 
scheduled relative to some prescribed mis- 
sion event (e.g., the start of an orbit), with 
some prescribed tolerance on the start time. 


2.3. Alternative Approaches 

2.3.1. Brute Force and Constructive Techniques. 

From the very large size of (he solution space — even for 
very simple scheduling scenarios as trivial as the above 
examples — it becomes clear that the feasibility of finding op- 
timal schedules will depend on the feasibility of a method 
that does not rely on brute-force search (i.e., a search strat- 
egy that requires the examination/evaluation of every possi- 
ble solution (i.e., every possible schedule)). Inescapably, only 
an exceedingly large number could represent the size of the 
solution space for real-world scheduling scenarios for the ac- 
tual users of NASA’s space data-communications services, 
and the idea of examining all of the possible solutions is un- 
tenable without resorting to some truly exotic method, such 
as the yet-to-become-practical idea of quantum computing. 
The general problem of creating optimal schedules to satisfy 
users’ data-communications requirements cannot be solved 
using a single, general prescriptive formula, nor with brute- 
force search through the solution space, even with power- 
ful computers (possibly excepting future quantum comput- 
ers) and the most sophisticated graph or tree-traversal algo- 
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rithms (such as the A* algorithm [3, 21] (not to be confused 
with the set of all antenna IDs (Definition 37 (page 18)))). 
From the foregoing examples, it will have been seen that the 
general optimal-solution search problem cannot be attacked 
with such approaches. 

However, workable solutions can be generated with the 
techniques that are in use in the current operational schedul- 
ing system, and these solutions are free of violations of con- 
straints (e.g., RF interference, if this option is activated in the 
scheduler). However, there is no expectation that the current 
approach will produce solutions that are near optimum. Fur- 
ther, since an optimum solution (in the absolute sense) would 
necessarily remain unknown, it cannot be determined how 
nearly optimum these found solutions might be (and even 
if an upper bound on the difference could be calculated, it 
would be without benefit, since the approach of the present 
operational system offers no way to use the information to 
produce better schedules). 

2.3.2. Necessity of Special Search Techniques. 

From the foregoing, it becomes a convincing proposi- 
tion that neither a brute-force strategy nor the approach 
of the current or any previous NASA scheduling sys- 
tem can offer the possibility of discovering an optimal 
solution for realistic scheduling scenarios: other tech- 
niques are required. While brute-force search performed us- 
ing quantum-computing techniques might be explored 
in the future, a more immediately available approach is 
worth considering for the interim. Research and applica- 
tion experience since the 1980s has resulted in establish- 
ing the viability of probabilistic search strategies for certain 
types of optimization problems that have very large solu- 
tion spaces. In particular, genetic algorithms [2, 4, 9, 29] 
(or, more generally, evolutionary algorithms) have been 
successfully applied to scheduling and planning prob- 
lems [1, 5, 12, 16, 27, 28, 31]. While other probabilis- 
tic search strategies (under the heading of data-regression 
techniques) are invoked at a high level herein (see Sec- 
tions 7.2 and 11.5.2), their detailed treatment is beyond the 
scope of this disclosure. 

2.4. Evolutionary Search 

2.4.1. Genetic Algorithms. 

Genetic algorithms belong to a well-studied class of algo- 
rithms abstractly inspired by biological selection and gen- 
eration, individual inheritance and mutation, species adapta- 
tion, species survival, and fitness [11]. Both in the algorith- 
mic realm and in biology, selected individuals in each gener- 
ation mate and produce offspring. The offspring have some 
but not all of the traits of their parents, and in fact have new 


traits as a result of genetic crossover and mutation. Individ- 
uals die and make way for individuals in the new genera- 
tion, who will survive better or not, depending on their fitness 
for survival in their given environment — which environment 
will favor the more-fit individuals with more power to pro- 
duce offspring for the next generation. Over successive gen- 
erations, the principle of “survival of the fittest” implies the 
expectation that the survival of individuals will improve over- 
all, i.e., the average fitness of members of the population will 
improve progressively. 

2.4.2. Representations of Solutions of the Scheduling 
Problem. 

The present disclosure invokes the principles of genetic algo- 
rithms to attack the problem of scheduling space-data com- 
munications, with the incorporation of the further, secondary 
objective of minimizing the effects of RF interference in the 
optimization. (This further, secondary objective represents a 
primary example of the general constraint-satisfying capa- 
bilities of the disclosed algorithms and methods.) Under the 
conceptual description given above, a solution, by definition, 
is a schedule, and each member of each generation is a sched- 
ule to be evaluated for its fitness to survive into, and produce 
offspring for, the next generation. Each schedule itself would 
be represented as a data structure in computer memory, and 
essentially is a list of communications events each of which 
at least partially satisfies a user requirement for communi- 
cations services. The data structure that represents the whole 
current generation lists individual members of the generation. 
The data structure for an individual is subjected to evaluation 
by a fitness function that determines the individual’s surviv- 
ability or fitness, i.e., the degree to which the individual mea- 
sures up to prescribed criteria. 

2.4.3. Processes for Selection and Creation of Working 
Population Members. 

The fitness function is the essence of the problem to be 
solved by the genetic algorithm and remains unaltered for 
the duration of the entire search for a solution. Each member 
(i.e., each schedule) of a given generation would have a fit- 
ness score determined by the prescribed fitness function. In 
each generational cycle, to prepare a new generation, a pre- 
scribed process (sub-algorithm) operates to perform a selec- 
tion of individuals (schedules) to survive into the new gen- 
eration and/or to be used to generate offspring. Another pre- 
scribed process (sub-algorithm) then (a) creates the offspring 
of the selected individuals by mathematically transforming 
and combining their traits (i.e., the values in the data struc- 
ture representing an individual), and (b) adds new members 
using an algorithm for randomly generating new schedules, 
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to effect the probabilistic exploration of the entire solution 
space. The probabilistic nature of the exploration arises from 
the use — during the execution of both the selection process 
and the new-member-creation process — of random-number 
generators in the computing platform on which the genetic 
algorithm executes. More will be said in Section 2.4.9 con- 
cerning random numbers in relation to the algorithms dis- 
closed herein. 

2.4.4. Principle of Operation of Genetic Algorithms. 

Operation of the genetic algorithm begins with the creation 
of an initial population of some size. The manner in which 
the members of the initial population are generated can af- 
fect the search progress, although the nature of the algorithm 
tends to diminish the effect over the course of the search. A 
new generation results from applying a variety of mathemat- 
ical transformations not only to individuals (i.e., their data 
structures), but also to pairs of individuals in the current gen- 
eration, which each will already have been evaluated by the 
fitness function during the process of selecting the members 
of the previous generation to compose the current generation. 
The more-fit individuals, being relatively favored (and, con- 
sequently, more likely themselves to persist for multiple gen- 
erations), will have relatively more offspring than will result 
from less-fit individuals. However, randomly selected indi- 
viduals will also produce offspring at some rate, and new in- 
dividuals created by a random process are also introduced 
into the population at some rate. The new generation will 
then undergo the same process of evaluation and transforma- 
tion to result again in a new generation. After some number 
of repetitions of the foregoing generational process, the cur- 
rent generation will, with some likelihood, include individu- 
als that are more fit than the best members of any previous 
generation. Eventually, after many generations, the expecta- 
tion is that an additional iteration of the evolutionary search 
process will have a vanishingly small likelihood of produc- 
ing further significant improvement of the best individuals 
of the new generation over those of the previous generations 
(see Footnote 6 (page 42)). 

2.4.5. Progress of Evolutionary Search. 

After an expected initial rapid improvement in the fitness of 
the best individuals, each successive generation will see, on 
average, less and less improvement. There occasionally can 
be sharp improvements from one generation to the next. Such 
improvements can occur by virtue of the probabilistic nature 
of the genetic algorithm-based search strategy: occasionally, 
during the search, a newly created individual (schedule) will, 
by chance, be much better (as evaluated by the fitness func- 
tion) than any other individual found earlier in the search. In 


this way, the algorithm can find and explore another region 
with a local minimum/maximum — which, with some prob- 
ability, could be the global minimum/maximum. However, 
the search effort/time required to produce significant new im- 
provement in the best individuals eventually will become un- 
tenable. Ultimately, the search must be terminated and the 
best individual (or rather one of possibly multiple individ- 
uals having the same best value of the fitness score) would 
then be used as the search result — with no guarantee, how- 
ever, that this solution is in fact the absolute best, and, fur- 
thermore, with no good way to show that it is not. 

Exploration of the solution space using a genetic algo- 
rithm may entail certain difficulties that have been described 
in the literature, e.g., “premature convergence” and “genetic 
drift”. A determination of the degree to which such diffi- 
culties might be present in the disclosed methods and algo- 
rithms has not been undertaken and is beyond the scope of 
this paper. However, the disclosed methods and algorithms 
include the S* Algorithm (Section 6 (page 34)) that directly 
addresses these issues, effectively “tuning” the genetic algo- 
rithm that finds an optimal solution for a given space-data- 
communications-scheduling problem scenario. Further, Sub- 
section 1 1 .4 (page 49) presents methods and algorithms that 
effectively address similar issues relative to solving the gen- 
eralized problem. 

2.4.6. Effect of Internal Parameters of the Genetic 
Algorithm. 

A genetic algorithm, in the general case, has internal param- 
eters that affect the efficiency and effectiveness of the search, 
including — 

• the size of the initial population 

• the size of subsequent generations 

• the proportion of each generation that is selected ran- 
domly for survival into the next generation 

• the number of offspring produced by selected individu- 
als 

• the number of randomly created individuals added to 
each new generation 

• the mutation rate, (i.e., the number of new members cre- 
ated in each new generation via the mutation mecha- 
nism) 

• the crossover rate, (i.e., the number of new members 
created in each new generation via the crossover mech- 
anism) 

• the number of “gene” crossover points (where “gene”, 
informally, refers to values in the data structure that 
specifies an individual member of the population 
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It is natural to ask how best to set the values of the internal 
parameters when the objective is to run an implementation of 
the algorithm and achieve the greatest possible degree of ef- 
fectiveness and efficiency in generating an optimal solution 
to the scheduling problem. Some understanding of the effect 
of different combinations of the possible values of the param- 
eters can be gained through systematic experimentation — 
testing different combinations to reveal how they affect the 
efficiency and effectiveness of the search process. Such a pro- 
cess, if performed manually, would be time consuming and 
tedious. It also might present conceptual and theoretical dif- 
ficulties relative to drawing reliable conclusions. 

By asking what might be the best combination of the val- 
ues of the internal parameters, one then sees another, some- 
what more abstract optimization problem. The author’s im- 
plementation of the unpublished predecessor of the herein 
disclosed algorithm included the use of a genetic-algorithm 
approach to solve this problem as well, to derive an optimal 
combination of those values. Details of this optimization ap- 
proach are found in Section 6 for the schedule-generation al- 
gorithm to be presented in Section 5 and (relative to the gen- 
eralization of the algorithms and methods that will be pre- 
sented in the main body of this disclosure) in Appendix B 
(Subsection 11.4 (page 49)). 

2.4.7. Fitness Functions, Minima, Maxima, and Optima. 

The fitness function applied to an individual (i.e., a sched- 
ule) in a given generation will produce a numerical value. 
In principle, the fitness score could be determined for ev- 
ery schedule in the entire solution space. If this were done, a 
kind of hypersurface (representing the fitness score (the de- 
pendent variable) as a function of the schedule (the indepen- 
dent variable)) could be constructed and analyzed mathemat- 
ically, and could be visualized as having contours, peaks, and 
valleys. The visualization of the function would also exhibit 
discontinuities resulting from, for instance, the discreteness 
of the allowed values for many of the parameters in the def- 
inition of a communications event. The sheer magnitude of 
the size of the solution space makes such a surface infeasible 
to construct, but the very class of probabilistic exploration al- 
gorithms we are concerned with in this disclosure could (if 
desired) even be used to approach the question of character- 
izing how “nice” the hypersurface is. In any case, the dis- 
closed algorithm is well suited to exploration of the whole 
solution space, “nice” or not. 

The essence of the optimization question pertains to find- 
ing the global maximum (or the global minimum, depending 
on how the fitness function is defined) of the search space. 
No known practical method exists to reach an “absolute” an- 
swer to this question for the general case. At this time, no 
other available method has been shown to surpass the re- 


sults that can be attained through a method based upon evo- 
lutionary (probabilistic) search: no known non-probabilistic 
method for addressing the general scheduling problem has 
been shown to be capable of surpassing the results that can 
be attained using available probabilistic search methods. 

The term optimizing, as applied to the algorithms de- 
scribed herein, reflects this aspect of directed, iterative prob- 
abilistic search, where the search space is probed by a ran- 
dom process to find more and more minima/maxima (local 
as well as global), and by another process that gives each 
of the best candidate solutions from the current generation a 
chance to have “children” that are still more fit as solutions 
to the scheduling problem. 

In general, the nature of the problem, with its extremely 
large solution space, leaves open the possibility that, at the 
termination of any arbitrarily long run of the application pro- 
gram on a computer, a “better” solution might have been 
found by letting the application produce just one more gener- 
ation. When the run is terminated, the best solution found is 
considered to be optimized in terms of the probabilistic cov- 
erage of the entire search space. This is the primary sense in 
which the term “optimal” is used in this disclosure, but there 
is, in a practical vein, an additional consideration, namely, the 
cost of the process of searching through the solution space 
for the best possible solution. Absent any limit on the speed 
or storage capacity of computing resources, there would be 
no trade-off between solution quality and search time. Actual 
limits on computational speed and storage will necessarily 
mean that, for any computer application that solves the kind 
of optimization problems addressed herein, solution optimal- 
ity will be directly related to the duration of the run of the ap- 
plication, which can never be unbounded. Thus, the designa- 
tion of “optimal” implies that enough computing power has 
been applied to reach a point where the law of diminishing re- 
turns (or at least a similar principle; see Footnote 6 (page 42)) 
would mean that a relatively large additional search effort 
would not have any significant expectation of improvement 
in the best solution found to that point. Conversely, if such a 
point has not been reached, then nothing can be asserted as 
to the optimality of any solution found. 

An unavoidable issue arises from the above discussion — 
the question whether it could be determined in advance what 
computing resources would be sufficient to reach the point 
described in the preceding paragraph (i.e., the point where 
it would be legitimate to declare that no reasonable addi- 
tional search time would provide any reasonable expecta- 
tion of significant improvement in the solution found). No 
known method can answer this question, except the em- 
pirical method, i.e., experimentation, although the kind of 
algorithm-performance modeling described in Appendix A 
may afford additional insights. 
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2.4.8. Metrics for Evaluation of the Scheduling System. 

Possible metrics to evaluate a scheduling system include 
(a) determining the percentage utilization of service-delivery 
assets (e.g., TDRSS antennas) and (b) assessing the de- 
gree of satisfaction of customer requirements. The current 
NASA scheduling system, based on constructive techniques 
or graph-search techniques, does not incorporate a strategy 
for constructing solutions that will directly optimize these 
metrics. The herein disclosed algorithm, incorporating some 
of the various possible metrics, lends itself to incorporation 
of a wide range of possible combinations of metrics to meet 
future goals for overall infrastructure performance. However, 
a full discussion of the possible metrics for evaluating the 
scheduling system is beyond the scope of this disclosure. 

Directly comparing the current operational system with 
one following the present disclosure might be accomplished 
by evaluating schedule quality using the herein disclosed fit- 
ness function (see Definition 103 (page 28)) or a combination 
of its constituent submetrics (e.g., the function satisfied* (see 
Definition 101 (page 28)), which measures the degree of sat- 
isfaction of data-retum requirements of all users.) 

2.4.9. Random Numbers and Their Role. 

Random numbers play a crucial role in the probabilistic 
search strategy and algorithms embodied in the present dis- 
closure, including the schedule-generation algorithm (Al- 
gorithm 1 (page 32)) and the S # algorithm (Algorithm 2 
(page 32)), as well as algorithms in Appendix B (Section 1 1 
(page 45)). 

It is noted that “random” numbers are generated by spe- 
cial software or hardware on the platform that constitutes 
the computing resources on which an implementation of the 
herein disclosed algorithms will ran. On typical platforms, 
the random-number generator implements a special algo- 
rithm that can be configured with a “seed” as the starting 
point for calculations to produce a random number. Repeata- 
bility of results can be assured by selecting the same seed 
for repeated runs — which is a feature that supports applica- 
tion software testing and debugging. The generated random 
numbers are not truly random, which is a well recognized as- 
pect of all known algorithms for generating random numbers. 
Interestingly, characterizing the difference between the out- 
put of random-number generators and the output of true ran- 
dom processes is not a settled matter, necessarily involving 
arcane argumentation. 

The fact that the generally available random-number gen- 
erators do not produce “true” random numbers does not in- 
validate their use in ordinary applications (such as the one 
described in this disclosure), where their use is generally ac- 
cepted. We accept the proposition that the use of a true (or at 


least the best possible) random-number generator would not 
improve the results or performance of a system that imple- 
mented the algorithms disclosed herein. 

3. Communications-Scheduling 
Assumptions 

3.1. Necessary Input Data 

The disclosed method and algorithm assume the availability 
of inputs from a computational resource that provides the fol- 
lowing information: 

• predicted user-communications view periods relative to 
each NASA support antenna 

• user-spacecraft orbit start and end times, with orbit 
numbers 

• start and end times for intervals during which the user’s 
Project Operations Control Center (POCC) (or, synony- 
mously, Mission Operations Control Center (MOCC)) 
is in operation 

• start and end times for other relevant mission events 
(user-spacecraft sunrise, user-spacecraft-over-land, 
etc.) whenever there are active user requirements that 
specify any relationship to such events 

• potential-interference intervals (predicted intervals dur- 
ing which RF signal interference would prevent NASA 
from satisfying a particular user requirement or request 
for communications services) 

• intervals of predicted user-antenna blockage and multi- 
path interference with respect to each support antenna, 
based on planned user-spacecraft attitude profiles 

• outage intervals (predicted/planned intervals dur- 
ing which service-delivery resources will be unavail- 
able) 

Such a computational resource, the Communications Link 
Analysis and Simulation System (CLASS) [8, 14, 19], has 
been in operation at the NASA Goddard Space Flight Center 
since the early 1980s. The CLASS system was used in gener- 
ating input data for runs of the prototype implementation of 
the predecessor of the disclosed algorithm, which implemen- 
tation is described in Section 8.1. 

3.2. Scope Limitations 

3.2.1. Two- Week Scheduling on a Weekly Cycle. 

NASA’s present operational scheduling system per- 
forms the scheduling function on a weekly basis for a 
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two-week scheduling period. The second week of the pre- 
viously generated two-week schedule becomes the first 
week of the new two-week schedule and is adjusted by the 
scheduling system to reflect updated or revised informa- 
tion concerning user requirements, planned outages, and 
other factors. The second week is scheduled afresh. Al- 
though it was not a design goal of the algorithm disclosed 
herein, it could be revised to provide this rescheduling func- 
tionality. However, it may be appropriate to reconsider the 
need for a two-week scheduling cycle when a new opti- 
mal schedule could efficiently be generated weekly (or 
on demand) by means of the method and algorithm dis- 
closed herein. 

3.2.2. Dynamic Rescheduling. 

Although NASA’s present operational scheduling system can 
perform rescheduling under dynamic operational conditions 
(where, for example, a spacecraft has a declared emergency, 
or a service-delivery resource has an unplanned outage), 
rescheduling is not considered herein and does not corre- 
spond to a design goal of the disclosed algorithms. Further 
discussion of dynamic rescheduling is beyond the scope of 
the present disclosure, but it has not been seen to present 
technical difficulties in a possible revised version of the dis- 
closed methods and algorithms. 

3.2.3. Near-Earth Communications Environment. 

NASA has been pursuing goals for crewed (as well as new 
un-crewed) missions that may be developed to explore the 
Moon and Mars over the next several decades. Such mis- 
sions crucially depend on adequate communications involv- 
ing RF links between the Earth and numerous remote as- 
sets including the mission vehicles and habitats. The future 
evolved infrastructure to provide the needed communications 
capabilities is in the early stages of definition, but is likely 
to have considerable similarities to the current space data- 
communications infrastructure serving near-Earth missions. 
For example, it is likely to have capabilities for “demand ac- 
cess” as well as a large reliance on scheduled communica- 
tions events, where infrastructure support antennas and as- 
sociated equipment would be scheduled to be configured to 
support user assets. While it was not a specific design goal 
to include the non near-Earth infrastructure in the disclosed 
methods and algorithms, the essential concepts already em- 
bodied in the present near-Earth infrastructure would con- 
tinue to be applicable. The one major issue that would need 
to be addressed for the non near-Earth infrastructure pertains 
to RF signal latency due to the large distances involved, es- 
pecially between the Earth and Mars. 


4. Definitions 

4.1. Basic Space-Data-Communications 
Definitions 

CLASS — Communications Link Analysis and Simulation 
System. CLASS is a software system developed, main- 
tained, and operated at NASA Goddard Space Flight 
Center for the purpose of supporting all aspects of space 
communications including spacecraft and communica- 
tions infrastructure design and operations. (See Subsec- 
tion 1.3 (page 5) and Section 3.1 (page 14).) 

Communications View Period — A time interval dur- 
ing which a given NASA service delivery antenna 
is capable of being pointed toward a given user as- 
set (spacecraft, rover, etc.), with a clear RF path that 
will permit data transfer using radio signals that have 
prescribed characteristics (frequency, power, polar- 
ization, etc.). (See formal definition of M (and the 
explanation), Definition 47 in Subsection 4.3, page 19.) 

Epoch — A date and time specified precisely and used as 
a reference time to specify later points in time as off- 
sets from the epoch. For example, a NASA mission may 
specify time as seconds of offset from the epoch date 
and time of 00:00 Hours on 1 January 1970. 

Forward — The direction of data flow from a NASA sup- 
port antenna to a user asset (spacecraft, rover, etc.). 
(Note that this definition may admit some ambiguity 
under various operational circumstances using particu- 
lar protocols (e.g. “acknowledgment” protocols as used 
in standard communications networks). The term is es- 
sentially meaningless in the context of two-way voice 
communications over a space communications link.) 

Link — An established RF connection between a transmit- 
ter and receiver configured with compatible signal fre- 
quencies, polarization, framing, coding, and data for- 
mats, with sufficient received signal power to enable 
data transfer. The description of such a connection. 

MA — Multiple Access; identifies the electrically “steer- 
able”, phased-array antenna on a TDRS spacecraft. See 
definition of SA. MAF/MAR: MA Forward/Retum. 

MOCC — Mission Operations Control Center. A facility 
housing personnel, equipment, software systems, and 
other resources, with necessary communications inter- 
faces with external entities, for the control and opera- 
tion of a space mission. Synonymous with Project Op- 
erations Control Center (POCC). 

Outage Interval — A planned or anticipated interval during 
which a service-delivery resource will not be in service. 
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This includes intervals designated for equipment main- 
tenance, upgrade, or calibration. (See formal definition 
of O, Definition 40 in Subsection 4.3, page 18.) 

POCC — Project Operations Control Center. Synonymous 
with Mission Operations Control Center (MOCC). 

Potential Interference Interval — A predicted interval dur- 
ing which unacceptable RF interference would affect 
signals received by either a user antenna or a service- 
delivery antenna. (See formal definition of I, Defini- 
tion 50 in Subsection 4.3, page 19.) 

Priority — A NASA-assigned numerical value that estab- 
lishes the order of precedence of a given user relative 
to others, for the purpose of determining which of any 
two users will have precedence whenever they are in dy- 
namic contention for NASA communications services. 
(See formal definition of <E>, Definition 51 in Subsec- 
tion 4.3, page 20.) The priority value is increased when 
a user has a declared contingency (e.g., the unexpected 
failure of a gyroscope on a spacecraft), although such 
a circumstance is not relevant for a scheduler, since by 
definition a declared contingency is not planned. 

Return — The direction of data flow from a user as- 
set (spacecraft, rover, etc.) to a NASA support antenna. 
(See remark under “Forward” regarding ambigu- 
ity of the term in certain circumstances.) 

SA — Single Access; refers to the two steerable dish an- 
tennas on a TDRS spacecraft. See definition of 
MA. KSAF/KSAR: K-band SA Forward/Retum. 
SSAF/SSAR: S-band SA Forward/Retum. 

Schedule — A collection of communications support events 
placed on a time line for a given time period (typically 
two weeks) and identified by a set of parameter values 
that enable the NASA communications infrastructure to 
be properly configured to provide communications ser- 
vices to users. (See formal definition of 0 in Subsec- 
tion 4.3, page 23.) 

User — A spacecraft or (depending on context) its as- 
sociated mission project that is authorized and 
properly configured to make use of NASA space 
data-communications services. A user can also be a 
rover on the surface of the Moon, or a special de- 
vice on the Earth’s surface designed to enable calibra- 
tion of TDRSS ranging capabilities. An example of a 
user is the Hubble Space Telescope. 

User Requirement (or User Request) — A specification of 
data-communications services needed by a user. Such 
a specification can be either specific or generic. Spe- 
cific requirements give start time and end time either 
as absolute times (e.g., as a date and time in the Ju- 
lian calendar or as seconds of offset from a prescribed 


epoch) or as seconds of offset from a prescribed mission 
event (e.g., spacecraft sunrise in orbit number 694). A 
generic requirement represents a repeating support ser- 
vice, with start and end times always defined in terms 
of a repeating mission event such as spacecraft sunrise. 
For both specific and generic requirements, the specifi- 
cation refers to some user-defined prototype communi- 
cations event (see formal definition of C, Definition 54 
in Subsection 4.3, page 20), which defines the commu- 
nications links required for each instance of the event, 
along with other relevant parameters. 

4.2. General Notation 

The formal specifications of the herein disclosed algorithms 
depends on precise mathematical notation (in particular, set- 
builder notation) involving a number of general terms and 
symbols defined as follows. 

Definition Is • (pronounced “bullet”) is a placeholder sym- 
bol representing any allowed value in the indicated place in a 
formula or expression, without regard to which allowed value 
might be chosen. 

Definition 2 (Universe): O is the universe of discourse, i.e., 
the set of all objects that can be a member of a set defined in 
the present disclosure. 

Definition 3 (Empty Set): 0 denotes the empty set, i.e., the 
set that has no member. 

Definition 4 (Set of All Integers): Z is the set of all integers. 

Definition 5 (Set of All Nonnegative Integers): N is the set 
of all nonnegative integers. 

Definition 6 (Set of All Positive Integers): N + is the set of 
all positive integers. 

Definition 7 (Cardinality): MQ C O, Q denotes the cardi- 
nality of Q (i.e., the number of members of Q).n = \Q\ 
n e N and Q has exactly n members. 

Note that |0| =0. 

Definition 8 (Set of All Finite Sets): 

O f C p(0) 9 Q e O f <£> 3n e N 9 |Q| = n. 

O f is the set of all finite sets. 

Definition 9 (Cartesian Product): MA, B C O, the Cartesian 
product A x B = |(a, h) : a £ A,b G h|, i.e., Ax B is 

the set of all ordered pairs (a e A, b e B). MQ C O, Q 2 = 
Q X Q. [Q C O, 2 < n <E N] Q n = Q x Q"" 1 . 

Definition 10 (Function): MA, B CO, f is said to be a func- 
tion from A to B, denoted by f: A — > B, if and only if 
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f C A x B 3 (a, b), (a, c) G / => b = c. A function is con- 
sidered to be a mapping from a domain to a codomain. If 
/ is a function, dom(/) denotes {a: (a, •) G /}, the do- 
main of /, and codomain(/) denotes {6: (•, b) G /}, the 
codomain of /. 

Definition 11 (Set of All Functions From Y to X): 

VX,Y C Q,X Y = {/: [/: Y -► X] }, the set of all 
functions from Y to X. 

Note that in some contexts (when either X or Y is not a set), 
the meaning of X Y differs (e.g., see Definition 57 (page 21)). 

Definition 12: Vf€X Y y g eZ x ,gofe Z Y . 

The symbol o (read as “circle” or “composed with”) denotes 
“function composition”, representing the process of using the 
output of one function as the input to another. In performing 
the process for a given value a in Y (the domain of /), the 
function / is used to obtain the value f(a) (a value in X (the 
codomain of /)), and this output from / is used as the in- 
put to the function g (whose domain is X) to obtain the value 
g(f(a)), which is a member of Z, the codomain of g. Thus, 
g o / is a function mapping Y to Z. 

Definition 13 (Power Set): VQ C Q, p(Q) denotes the 
power set of Q, i.e., y G p(Q) y C Q. 

The power set of Q is the set of all subsets of Q. 

Definition 14 (Set Difference): VQ C 0,VA C Q,Q\A = 
{x G Q : -ix G A}, the set of members of Q that do not be- 
long to A. 

Q\A denotes set difference. 

Definition 15: mdint: Z x Z — > Z 9 i, j G Z, i < j => 
mdint(*,j) is a random integer in the closed interval [*, j] . 

mdint is a “pseudo-function” in the sense that, in any two in- 
vocations for the same arguments, it does not necessarily re- 
turn the same result, assured by the use of a randomizing 
mechanism in the processing system on which the applica- 
tion is running. 

A further note concerning functions is in order: except 
when a “pseudo-function” like mdint is involved, the mem- 
bers of the mapping (the ordered pairs) are fixed. 

Definition 16 (Set of All Closed Intervals): 

Z = {i : 3a, b gZ 3 a < hand* = [a, 6]}. 

Z is the set of all closed intervals having integer endpoints 
belonging to Z. 

Definition 17 (Left-Most and Right-Most Points of an Inter- 
val): V ?7 = [a, b] G Z, = a and rj + = b. 

Definition 18 (Ordering Relation for Intervals): 

V? 7 , /3 G Z, r] < P r) + < . 


This is the ordering relation for intervals. 

Definition 19 (Ordering Relation for Sets of Intervals): 

VA, B G p(Z),A < B <&■ [g G A, fi G B => r) < 0\. 

This is the ordering relation for sets of intervals. 

Definition 20 (Sequence): s is said to be a sequence if and 
only if 
sGfi N 3 

1. 3a G O 9 (0, a) G s and 

2. ( j G N + , •) G s => 3a G fi 9 (j — 1, a) G s. 

Note that the first element of a sequence has index value 

0, and that no index value between the first and the last is 
skipped. 

Definition 21: For each sequence s, if (*, a) G s, then a is 
denoted by s iy s[i], or s(i). 

Definition 22: For each finite sequence s, 

1. the number of elements of s is denoted by len(s) and 

2. s is represented as (so,si, . . . where 

n = len(s). 

Definition 23 (Tuple): Vn G N + , q is said to be an n-tuple 
if and only if q is a list of objects indexed by their position 
in the list, where the first element of the list has index value 

1, the second element has index value 2, etc., and the last has 
index value n. An ordered pair is a two-tuple. 

An alternative, and equivalent, representation for an n-tuple 
(<?i, < 72 , ■ ■ ■ , <7n ) would be the sequence (s 0 , Si, . . . , s n _i), 
where V* G {1, 2, ... , n}, Sj_ i = < 7 *. 

Definition 24: VQ C fi,Vn G N + ,n > 1 ,Q n de- 
notes the set of all n-tuples {qi,qi, - ■ ■ ,q n ), where 
V* G {1, 2, . . . ,n},qi G Q. 

Definition 25 (Subsequence): The sequence t is said to be 
a subsequence of sequence s if and only if 3r C s, 3 a se- 
quence q £ 3 

1. (i,(m,a)),(i+l,(n,b)) £q 

(a) m <n and 

(b) -i c)£r3m<k<n and 

2. t = | (i, v) : 3(m, v) G r 3 (i, ( m , t;)) G <7 j. 

Definition 26 (Set of Sequences of Members of a Set With- 
out Repeats): S* : p(fl) -» p(0 N ) 9 

MQ G p(D), s G S*(Q) s is a sequence 3 

1. (•, a) G s => a G Q and 

2. (i,a), (j,a) es^i=j. 
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For each set Q, the function S* defines the set of all possi- 
ble sequences of (not necessarily all) members of Q, with- 
out repeats, i.e., if s G E*(Q), then no member of Q appears 
twice in s. 

Definition 27 (Set of Sequences of Members of a Subset of 
a Set Allowing Repeats): S** : p(D) -» p(Q N ) 3 
VQ G p(0), s G S**(Q) =>• s is a sequence 3 
[(•,a) G s => a G Q]. 

Definition 28 (Set of Sequences of All Members of a Finite 
Set Without Repeats): 

S: fl F -» p(0 N ) 3 VQ G Ct F , s G E(Q) & 
s is a sequence 3 

1. len(s) = \Q\ and 

2. a G Q 3(«,a) G s. 

For each finite set Q, the function S(Q) defines the set of the 
sequences of all of the members of Q. 

Definition 29: rndmember : Q F -3 ft 3 

VQ en F ,3£e~(Q) 3 

rndmember (Q) = £[rndint(0, |Q|-i)]]. 

Given a finite set Q, mdmember(<5) returns a random mem- 
ber of Q. 

Definition 30: RND : N+ x Op -> fl F 3 

[Q G fl F , |Q| > n G N+ => 

RND(n, Q) = rndmember ({ /l C Q-. |A| = n}). 

Given a non-empty finite set Q and a positive integer n < 
\Q\, RND(n, Q) returns a random subset of Q whose cardi- 
nality is n. 

Definition 31: R is the set of all real numbers. 

Definition 32: max: p(lR) 3l3 

V bounded and closed subset Q G 1, 3x G Q 3 

1. y € Q => y < x 

2. max(Q) = x 

The function max returns the largest value in a set of numer- 
ical values. 

Definition 33: min: p(M) 3t3 

V bounded and closed subset Q G M, 3a: G Q 3 

1. y gQ y >x 

2. min(Q) = x 

The function min returns the least value in a set of numerical 
values. 

Definition 34: s is said to be a string if and only if s G 
S ** ({ 2 : : x is an ASCII character}) . 

Definition 35: S = (s : s is a string}. 


4.3. Domain-Specific Definitions 

4.3.1. System Input Data. 

Definition 36: .S'o = {s G S: s represents the ID of a sta- 
tion in either the Space Network or the Ground Network} 

The string “TDRS-B” is an example of a station ID. So is 
supplied as input data to the scheduling system. 

Definition 37: A* = {a G S: a represents an antenna ID} 

A* is supplied as input data to the scheduling system. 

Definition 38: A 0 C S 0 x A* x {“S”“K” ,“K1” ,“K2”}x 
• “MA”,“SA”} 3 

a = (ai,..., 04 ) G A 0 ,a 4 =“MA” => CI 3 =“S” 

A 0 contains a 4-tuple for each antenna in the communications 
support infrastructure. The elements of each 4-tuple identify 
the basic antenna attributes (the station where the antenna is 
located, the antenna’s ID, the antenna’s frequency band, and 
the antenna’s signal service capability). A 0 is supplied as in- 
put data to the scheduling system. 

Note: It is assumed that all SA antennas are able to sup- 
port S band. 

Definition 39: Sq A : So -3 N 3 s G Sq =>■ 

S$ A (s) = {a G A 0 : d = s, a 4 = “SA” } . 

Given station s, Sq A (s) returns the number of SA antennas 
in service at station s. This information is provided as input 
data for the scheduling system. 

Definition 40 (Outage Interval): O C Sq x A* x N 2 3 
(oi,...,o 4 ) G O => 

03 is a start time and 04 is an end time. 

O is the set of communications resource-outage intervals, 
each corresponding to times known in advance when data 
communications via prescribed antennas will be unavailable. 
O is supplied as input data to the scheduling system. 

Definition 41: Uo = {u G S: u represents a user ID} 

A user (see definition of User on page 16) is any system ca- 
pable of communications via an antenna in NASA’s space 
data-communications infrastructure. U 0 is supplied as input 
data to the scheduling system. 

Definition 42 (POCC Operation Periods): P: Uq -» p(Z). 

Given user u, P{u) is the set of time intervals during which 
the user’s Project Operations Control Center (POCC) is in 
operation. The intervals belonging to the set P{u) have start 
and end times specified as seconds of offset from some stan- 
dard epoch. If a POCC is always in operation, then there is 
only one interval specified, the start time of which is the start 
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of the scheduling period and the end time of which is an ar- 
bitrary, sufficiently large number. P is supplied as input data 
to the scheduling system. 

Definition 43: L* = {i £ S: i represents a link ID} 

L* is provided as input data to the scheduling system 

Definition 44: M* = {i £ S: i represents a mission event 
type} 

M* is provided as input data to the scheduling sys- 
tem. An example of the set of mission event types would 
be: {“NIL”, “ORBIT”, “COMM- VIEW-PERIOD”, “IN- 
VIEW”, “DAY-LIGHT”, “NIGHT”, “OVER- WATER”, 
“OVER-LAND”, “SUN-RISE”, “MOON-RISE”, “SUN- 
SET”, “MOON-SET”, “DAY”, “WEEK”, “MONTH”}. 
Some mission event types do not relate to a station in the sup- 
port infrastructure. For example, for the mission event type 
“MOON-SET”, a station ID is irrelevant, and so, for a mem- 
ber of M (see Definition 47, page 19) for that mission event 
type, the value of p 3 could be given as •. Mission event type 
“NIL” is reserved for cases where a user-support require- 
ment/request is specified in relation to an exact time interval 
(i.e., a “specific” requirement, as opposed to a “generic” re- 
quirement; see definition of User Requirement, page 16). 

COMM-VIEW-PERIODs are assumed to be intervals dur- 
ing which RF communications with a given user via a given 
network station are possible. COMM-VIEW-PERIODs are 
determined in advance (and are assumed herein to be pro- 
vided as input data), by considering all factors that affect 
communications performance, as computed, for example, by 
the NASA Communications Link Analysis and Simulation 
System (CLASS) [18] and the “Automated Conflict Resolu- 
tion System” and the “TDRS Look Angle System” [19]. It is 
assumed that, according to the mission plan, the spacecraft 
attitude will be adjusted and maintained as needed to enable 
the appropriate on-board antenna(s) to receive and/or radi- 
ate signals from/to the designated support antenna. 

Definition 45: L 0 CU 0 xL* x {“S”,“K”,“Kl”,“K2”}x 
(“MA”,“SA”} x (“FWD”,“RTN”} x {“RCP”,“LCP”}x 
N+3(Ai,...,A 7 )el 0 ^ 

1. A4 indicates which type of signal service (Multiple Ac- 
cess or Single Access) is required, 

2. A5 indicates the direction of data flow, 

3. A 6 indicates the signal polarization required, and 

4. A7 represents a data rate in units of Kbps (i.e., 10 3 bits 
per second). 


requests for communications services. L 0 is supplied as in- 
put data to the scheduling system. 

Definition 46: MAXALLOWEDRTNRATE is a fixed pa- 
rameter, provided as input data for a given scheduling sce- 
nario, applicable to the entire data-communications support 
infrastructure, defining the maximum allowed data rate (in 
units of Kbps) for all return-data communications links com- 
bined at any given instant. 

Definition 47 (Mission Event): M C f/ 0 x M* x Sq x N 2 3 
{px, . . . , p 5 ) £ M => 

1. /i4 is a start time 

2. p 5 is an end time. 


M, supplied as input data to the scheduling system, is the set 
of mission event instances. The preparation of M requires a 
computational resource such as CLASS. 


Definition 48: L: U 0 -¥ p{L 0 ) 3 
L(u) = | A = (u, A2 , . . . , A7) 6 Lo| 

For a given user u, L(u) is u ' s set of communications links. 
The function L can be regarded as a table of data supplied as 
input to the scheduling system. 


Definition 49: V : So x Uq -> p(M) 3 
(s,tt) £ S 0 x £ V(s,u) 

m = u, n 2 = “COMM- VIEW-PERIOD”, p 3 = s 


The function V, given (s, u) £ Sq x Uq, returns the set of all 
communications view periods for station s and user u. V, ef- 
fectively a table of data, is supplied as input to the scheduling 
system. 


Definition 50 (Potential Interference Intervals): 


: S 0 x L 0 — > p(Z) 3 
(s, s', A, A') £ Sq x Lq, £ £ I(s, s', A, A') 

3(p u ...,p 5 )£ V(s, Ai), 3(/4 ...,/4) e'w, Ai) 9 


l (c [m,p, 5 \ n K,/4] + 0. 

2. [t £ C, links A and A' are active at time t via stations 
s and s', respectively] o- link A suffers unacceptable 
degradation due to interference by link A', 

3. V/3 £ Z 9 C C / 3 , 3t £ ( 3 \( 3 at time t, 

(a) links A and A' are active via stations s and s', re- 
spectively, and 

(b) link A does not suffer unacceptable degradation 
due to interference by link A'. 


L 0 provides all relevant information about all users’ commu- 
nications links. The schedule-generation algorithm requires 
this information in order to find a schedule that will satisfy 


Potential interference intervals are supplied as input data by 
(for example) the NASA CLASS interference analysis sys- 
tem (IAS) (see Introduction, page 6). Note that CLASS can 
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supply potential interference intervals for the cases where a 
user’s communications link would be degraded by RF energy 
from a non-specific source such as cellular-telephone signal 
emitters or other non NASA sources such as radars. In such 
cases, the interfering “link” would have a CLASS-supplied 
link ID and user ID. 

Definition 51: <I>o: Uq -> N 3 Vu G (7o,<E> 0 (u) is the 
NASA-assigned mission-priority value 9 

| v! G Uq, u' ± u, and u' has lower priority than it] => 
$o(w') < 4>o(u). 

NASA-assigned mission priorities are supphed to the 
scheduling system as input data. 

Definition 52: $ : f/o-)l9 

u G Uo,m = max({:r: 3u' G Uq,x = 4> 0 (i/)})J =>■ 
i(it) = m _ 1 $o(u). 

supplied as input data to the scheduling system, maps 
NASA-assigned mission priorities to the interval [0, 1], 

Definition 53 (Service): Y C L 0 x N 4 9 
(A ,s-,s+,d-,d+) G Y =£• 

1. s - and s + represent, respectively, the minimum and 
maximum allowed start-time offset from some given 
reference time, and 

2. d~ and d + represent, respectively, the minimum and 
maximum allowed duration of the service. 


1. n G S represents a requirement ID, 

2. r 2 G Uq is a string representing a user ID, 

3. r 3 is a subsequence of the sequence C'(r 2 ), the list of 
prototype events prescribed by user r 2 , 

4. r 4 G M* is a string representing a mission-event type 
for user r 2 , 

5. r 5 e N is a mission-event skip factor specifying how 
many mission events of type r 4 must be skipped be- 
tween consecutive instances of prototype events in the 
sequence r 3 , 

6. r 6 e Z is seconds of offset of an instance of a proto- 
type event in the sequence r 3 from the start (if r 8 = 
“START”), or end (if r 8 = “END”) of a mission event 
of type r 4 , 

7. ry G Z is seconds of offset of an instance of a proto- 
type event in the sequence r 3 from the start (if rg = 
“START”), or end (if rg = “END”) of a mission event 
of type r 4 , 

8. r 8 G {“START”, “END”} indicates whether the start of 
a prototype event instance is relative to the start or end 
of an instance of a mission event of type r 4 , 

9. rg G (“START”, “END”} indicates whether the end of 
a prototype event instance is relative to the start or end 
of an instance of a mission event of type r 4 . 


y is the set of tuples (A, s~, s + , d~, d + ) that specify users’ 
services in terms of links, earliest and latest start-time off- 
sets, and minimum and maximum durations, and is supplied 
as input data to the scheduling system. 


Definition 54 (User-Prescribed Prototype Event List): 

C: c/o^s*(s*(y)) 9 


u G f/o, k G N + , k < len((7(u)), 
ieN,i< len(C'(ii) [fc]). 


C{u)[k][i] = (A, •,»,*,•) 


=> A € L(u). 


p is said to be a prototype event if and only if 3w e Uq 3 
(• ,P ) e C(u). 

C{u ) is the user-u prescribed list (sequence) of prototype 
communications events for user u. Every communications 
event scheduled by the algorithm for the given user u will 
match the values of some element of C'(it), with leeway on 
the duration and the start-time offset relative to a given proto- 
type event start time. The mission-operations project for each 
user u supplies the list C(u ) as input data to the scheduling 
system. 


Definition 55 (User Requirements): i?o is a set each element 
of which is an ordered 17-tuple (n, . . . , ri 7 ) 9 


1 0. no e N+ represents the total volume of data desired 
to be returned from the user spacecraft in units of 10 3 
bits during any instance of a prototype event in the se- 
quence r 3 , 

11. rn e (“Y”, “N”} indicates whether the user’s POCC 
must be open during an instance of a prototype event 
in the sequence r 3 , where “N” means the POCC is not 
required to be open, 

12. n 2 G {“Y”, “N”} indicates whether mutual interfer- 
ence may be neglected in scheduling communications 
events, 

13. ri 3 G N is the minimum allowed separation, in sec- 
onds, between any two consecutive instances of a pro- 
totype event in the sequence r 3 during any given com- 
munications event window as defined below, 

14. ri 4 G N is the maximum allowed separation, in sec- 
onds, between any two consecutive prototype event in- 
stances, 

15. ri 5 G N is the offset, in seconds, from the start of the 
scheduling period to the earliest time at which any in- 
stance of a prototype event in the sequence r 3 is allowed 
to start, 
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16. ri6 € N is the offset, in seconds, from the start of the 
scheduling period to the latest time at which any in- 
stance of a prototype event in the sequence r3 is allowed 
to end, and 

17. nr £ N is the nominal prototype-event start time off- 
set, in seconds, from the start of the scheduling period. 

R 0 , given as input data by the users, is a set each element 
of which is a user requirement. A requirement specifies ei- 
ther repeating or singleton (nonrepeating) communications 
events to satisfy the user’s needs for communications via sta- 
tions in the network. A requirement may specify (via param- 
eters ri3 through ri6, and via the last four parameters in each 
of the user’s defined services (see Definition 53 (page 20))) 
loose or tight tolerances on positioning of events in time. 

Example of a communications event window relative to 
the mission event type “SUNRISE”: Starting 20 sec before 
each third sunrise, ending 15 min after the sunrise. In this ex- 
ample, the mission-event skip-factor (r 5 ) would be 2. 

For every requirement r = (n, . . . ,ri 7 ) where the mis- 
sion event type is “NIL”, there is a mission-event instance 
p = (pi , . . . , p 8 ) in M where p 2 = “NIL” and [/X4, p$] = 
[rie, ri 6 ]- 

4.3.2. Scheduling-Algorithm-Specific Definitions. 

Definition 56 (Service Instantiation): 

Y 1 : Y->p(Nx A 0 xN 2 ) 9 

\/y=(X = (X u ...,X 7 ),s-,s+,d-,d+)€Y, 

0 t,a,s,d ) G Y l (y) <=> 

1. a = (01, 02, 03 = A3, 04 = A4) G Aq, 

2. s~ < s < s+, and 

3. d~ < d < d + 

Y l returns, for each defined service y, the set of all pos- 
sible instantiations ( t,a,s,d ) of y where the link might 
be activated on the assigned antenna a during the interval 
[(t + s), (t + s + d)]. 

Definition 57: Y v :NxMxY->-Z9 

y = (A = (Ai, . . . , A 7 ), *-,*+, •, d+)) G 

NxMxY9^ = Ai,/g V(pJ, p y ) J =► 

Y v (t, p v , y) = \pj, pj] n [(t + s~), (t + s+ + d + )] . 

Y v (t, p y , y) is the largest interval during which the service y 
instantiation, relative to the given offset t from the start of the 
scheduling period, would overlap the given view period p Y . 
The interval Y v (t, p y , y) covers any possible instantiation of 
y relative to the given view period p y and the given offset t 
from the start of the scheduling period. 


Definition 58: U : Rq — »■ Uq 9 

r = (n,-. . ,r 17 ) £ Rq => U(r) = r 2 . 

U (r) represents the user for which r is a prescribed require- 
ment. 

Definition 59: M type : Rq -> S*(S*(M)) 9 
Vr= (n,...,n 7 ) eR 0 , 

Mype(r) = £ G S*(H*(M)) & 

1. [iGN,i< len(£)] =*> &[1] = r 2 and & [2] = r 4 and 

2. [i,j G < j < len(f)] => 

< [4i [4] , [5]] 

Given r £ Rq, M tyve (r) is the time-ordered sequence of all 
the members of M for user r 2 that have mission event type 
r 4 . 

Definition 60: M T : {“START”, “END”} x M -> N 9 
{x, p = (p u p 5 )) £ dom(M T ) =*► 



if x = “START” 
if x = “END” 


Mi returns a start time or an end time for a given mis- 
sion event. The returned time is the reference time relative 
to which a prototype event will be instantiated according to 
re- 


Definition 61: tref: Rq xM — » Z 3 

(r = (ri, . . . ,ri 7 ), p = {pi,...,p 5 )) £ Ro x M, 
Pi = n,P2 = T4, 

[r 4 = “NIL” =► t p = ri 5 ] , 

[r 4 / “NIL” =>• t p = M T (r 8 ,p) + r ( 
tref(r, p) = t p 


tref(r, p) returns the reference time specified by requirement 
r relative to any mission event p of type r4, with respect to 
which any prototype communications event would be sched- 
uled, subject to the skip factor r 8 . 

Definition 62: M sk j ps : i?o x N -¥ E* (N) 9 
V(r= (n,...,n 7 ),i) Gi? 0 xN, 

Mfldps (r,i) = £ G 5*(N) <£> 


L i < r 5 , 

2. n = len(Mtype(r)) =>• 

>en(0 = n — n mod (rs + 1) /(rs + 1), and 

3. [j £ N, j < len(0] £\j] = j(r 5 + 1 )+i 


Af skips (r, i) is the list of indexes into M t ype(r) such that, start- 
ing with the mission event instance M iype (r)[i], these ele- 
ments of M type (r) correspond to the mission event instances 
determined by applying the skip factor r$. The concept (see 
Figure 4.3.2 (page 22)) of applying a skip factor having the 
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value n entails the process of (1) starting with some given 
mission event instance, (2) ignoring (i.e., skipping) the next 
n mission event instances, (3) keeping the next mission event 
instance, (4) skipping the next n mission event instances, etc. 
Note that in normal practice, the starting point for the pro- 
cess will be not some arbitrary member of M type (r), but in- 
stead will be Mtype(r) [0], i.e., the first mission-event instance 
of type r 4 . This practice satisfies the normal mission expec- 
tation that in maximizing the satisfaction of mission require- 
ments, no opportunities for enabling data communications 
will be foregone. 


Instances of mission event of a 
type specified by parameter r 4 : 

_ ' W\ - 

3 12 3 45 6 7 8 9 10 11 

I '^""'""'^indexes into M typc (r)^' , 

1 I I 1 

2 5 8 11 

X ^ 

M typc (r) indexes listed in M skips (r, 2) 

(with rs = 2) 


Figure 3. An example illustrating the skip- 
factor concept. Twelve instances of a mission 
event of type r 4 are shown along the time line. 
These instances have indexes 0 through 11 in 
the sequence Mtype(r). The relevant parameter 
values (see Definition 62 (page 21)) in this ex- 
ample are the skip factor, r 5 = 2 , and the index, 
i = 2 , of the first (i.e., the left-most) instance of 
a mission event of type r 4 where an instance of 
a prototype event is to be scheduled. Thus, af- 
ter skipping the next two instances of a mis- 
sion event of type r 4 , the next index in the 
list is M sk ips(r, 2)(l) = 5. Note, however, that 
in normal practice, the starting point for this 
process will be not some arbitrary member of 
Miy pe (r), but instead will be Mty pe (r)[0], i.e., the 
first mission-event instance of type r 4 , corre- 
sponding to setting the index i to 0 . 


Definition 63: P max : Ro x Z -> Z 9 

(r, j3) € Ro x Z, P max (r, 0) = C G Z 4=> 

1. C G P(U(r)), 

2. g = ( n j3 0 0, and 


3. g £ P(U(r)),h = r] fl /3 =>• g + — g > h + — h 

P mm (r, 0) returns the POCC operation period for user U (r) 
that has the largest intersection with the given interval 0 

Definition 64: : R 0 x N 2 x M 2 -»• N x A 0 x N 2 9 

V(r= (n ,...,r 17 ),k,n,fj, = (r 2 ,r 4 ,/i 3 ,j[i 4 ,/i5), 

= (til, ■■■, til)) G dom ( y max)> 

y max( r > fc > n >M>At V ) = (tp, a ,S,d) <S> 

1. (tp, a = (ai, . . . , a 4 ), s, d) 6 codomain(3^ ax ), 

2. p y 6 y(ai,r 2 ), 

3. t p = tref(r,/z), 

4. k < len(r 3 ), 

5. n < len(r3[fc]), 

6. (t p ,a,s,d) € ^(rs [*:][«]), 

7. (oi = ai,o 2 = a 2 ,a 3 ,o 4 ) e O =>• 

[o 3 , o 4 ] n [(tp + s), (tp + s + d)] = 0 , 

8. r 4 = “NIL” ,[/x 4 , /i 5 ] = [ri5,n 6 ], 

/3 = Y y (t p ,fj0,r 3 [k\[n])),l3 ± 0, 

[fit = “N” , T] = 0]v 

[ni = “Y” , C = Pm*x(r, 13 ), 77 = C n 0] V 

r 4 7^ “NIL”, £ = [tp, ^5], 

13 = £n Y y {t p ,p y ,r 3 [k\[n\)),p ± 0, 

[fn = “N” ,T) = 0\v 

[ r ll = “Y” ,C = Pmax( r , = C n /3]] , 

9. t p + s = r]~ ,d = rj + — (t p + s) > 0 

Y^ lax ( r ,k,n,ti,ti V ) gives the largest interval in the given 
view period p y where, (a) with respect to [ris,ri6] (when 
r 4 = “NIL”) or (b) with respect to the given mission event p 
(when the given requirement specifies the start of the given 
prototype event in relation to the given mission event), the 
given service (stipulated by (r, k, n )) can be instantiated with 
an antenna assigned avoiding any resource outage. 

Definition 65: 

^rPRM. x Rq x M — > p(S*(codomain(y 1 ))) 9 
[(k,r= (r 1 ,...,r 17 ),p= (/t 4 = r 2 ,/t 2 = r 4 ,.. .,/t 6 )) 
€ dom(C'o RM ), 

P G C’o RM (fc,r,/i)] 

1. k < len(r3),Ien(/>) = len(r 3 [fc]), 
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2. t p = tref(r, p),n eN,n < len(p)J => 

(a) 3 (t p ,a,s,d) G ^’(^[^[n]) 9 

p[n] = ( t p ,a,s,d ), 

(b) 3 M v = (tf ,. . . , G M, 3[s*, <f] G Z, 

3(t p ,a,s*,d*) = 5^„(fc,r,n,/i,/i v ) 9 

[«,( S + d)]C[ s *,( s * + «0] . 

C'q RM (/c, r, is the set of all possible instantiations of the 
kth prototype event in the list r 3 for the mission event p of 
type r 4 , with antenna assignments avoiding resource outage 
intervals. 

Definition 66 (Set of All Possible Schedules): 

0 C codomain(C' PRM ) 9 V# G 0, 

(k,r= (n,...,r 17 ),p= (pi = r 2 ,P 2 = n,...,p 5 )) 
G N x R 0 x M, 
k < len(r 3 ), 

x G C^ iM {k,r,p),y G C^^r,^), 
x G 9, and y G 9 => x = y 

0 is the set of all possible schedules. 

A schedule is a set of prototype-event instantiations, with 
no more than one such instantiation for each instance of the 
mission event type stipulated by each requirement. 

For each (k,r = (ri, . . . ,r 17 ),p = (r 2 ,r 4 , . . . , p 5 )) G 
N x Rq x M, with k < len(r 3 ), the scheduling objective 
is to schedule an instance of the prototype event r 3 [fc] so as 
to transmit a total quantity of data equal to ri 0 x 10 3 bits, 
subject to 

• the minimum and maximum comunications-event sep- 
arations ri 3 and ri 4 and 

• the mission-event skip factor r 3 . 

Definition 67: skipsat R * : 0 x Ro -» R 9 

(0,r= (n,...,n 7 )) G 0 x Rq, 
n = len(M skips (r,0)), 

Q = jp: 3j, k G N 9 j < n, k < len(r 3 ), 

p G (k, r, M type (r) M skips (r, 0) [j]j ) , 

P G <?}, 

h = max^{10 -3 , |Q|})j => 
skipsat R *(0,r) = nh _1 

Given a schedule 0 and a requirement r, skipsat R * returns 
a value representing the ratio of the number of elements in 
Mskips 0) to the number of prototype events scheduled for 
the members indexed by M si3ps (r, 0). This final value will be 


exactly 1 if the skip factor requirement is satisfied (the pos- 
sibility that prototype event instances will be scheduled for 
other mission events is irrelevant for this metric), and will 
be a larger value otherwise. The assumption is that, from 
the start of the scheduling period, the first mission event of 
type r 4 will have a mandatory first prototype-event instanti- 
ation, then r 5 mission events of type r 4 will be skipped, and 
then the next mission event of type r 4 will have a manda- 
tory prototype-event instantiation, with this pattern repeated 
for the remainder of the scheduling period. 

Definition 68: violations SKIP * : 0 — > R 9 
6 G 0 =>• violations 8 ™** ( 9 ) = 

\Ro\ 1 skipsat R *(0, r) 

rERo 

Given a schedule 0, violations 8 ™** returns the total of the 
metrics for all requirements as to how well their skip factors 
are satisfied — averaged over all requirements. For a perfect 
schedule, this metric will be exactly 1, and will be a larger 
value otherwise. 

Definition 69: skip FILL R * : 0 x i?o -> R 9 

{6,r= (ri,...,n 7 )) G 0 x Ro,N = len(M type (r)), 
h = len(M type (r)) — len(Af S ] t i ps (r, 0)), 

Q = jp: 3m, k G N, k < len(r 3 ), 

m < len(Mtype( J '))> ~'m G Afskips( J '> 0 , 
p G C£ RM (k, r, Mtype(r) [m]) , p G 0 j =S> 
skip FILL ' R * (9, r) = l + h- 1 \Q\ 

Given a schedule 9 and a requirement r, skip Fnj " R * returns 
1 plus the ratio of | Q \ (the number of prototype-event instan- 
tiations that are not required under the mission-event skip re- 
quirement r 5 for mission events of type r 4 ), to h (the number 
of mission event instnaces of type r 4 that are required to be 
skipped). This metric has the value 1 if (he schedule is perfect 
(i.e., there are no prototype events instantiated when not re- 
quired), and has a greater value otherwise. See the statement 
of the assumption under Definition 67. (Note that h = 0 cor- 
responds to an impossible condition, namely, that all of the 
instances of the mission event of type r 4 are to be skipped.) 

Definition 70: yiolations SKIPrlLL ’ : 0 -» N B 
9 G 0 =► violations SKlpriLL ’ (9) = 

|j?o| _1 E skip FILL ' R *($, r) 
rERo 

QlTTpij'H T If, 

Given a schedule 9, violations returns the to- 

tal count, for all requirements r, of prototype-event instanti- 
ations that are not required under the mission event skip re- 
quirement r 3 for mission events of type r 4 — averaged over 
all requirements. 
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Definition 71: start p : codomain ((7 PRM ) -> N 3 

1. p 6 codomain(C'o RM ) =>• 3(fc, r,/i)eNxiJoxM9 

P G Co KM (k, r,p), 

2. = {n: 3(t, •, s, •) G p 3 v = t + s}J => 

start p (p) = min (Q) 

Given the instantiation p of a prototype event, start p (p) re- 
turns the earliest start time of any service instantiation in the 
event. 

Definition 72: end p : codomain(C' PRM ) ->ff3 

1. p e codomain(C' PRM ) =>■ 3(fc, r,/i)€Nxi?oxM9 

P G C'o RM ( fc > r >/ i )> 

2. [q = {n: 3(t, •, s,d) € p 3 v = t + s + d}J =>• 

end p (p) = ma x(Q) 

Given the instantiation p of a prototype event, end p (p) re- 
turns the latest end time of any service instantiation in the 
event. 

Definition 73: minsepsat 1 ’* : 0 x Rq -> N 3 

(0,r= (n,...,n 7 )) e&xRo, 

Q = {(p,P') €6x6: 3 (k,r,p) € N x Rq x M B 

p € C'o RM (fc,r,/i), 

3 {k,r,fj,') eNxRoxMBp' € C^ M (k,r, p'), 
start 1 * (j/) > end p (p) 

start 1 * (p') - end p (p) < ri 3 }J => 

minsepsat 1 ’ \0,r) = \Q\ 

Given a schedule 6 and a requirement r, minsepsat 1 ** {0, r) 
returns the total count of pairs of prototype-event instantia- 
tions for requirement r in 8 that are separated by less than 
the minimum allowed separation 7*13. 

Definition 74: maxsepsat 1 ** : 0 x Rq -> N 3 

(0,r= ( ri,...,ri 7 )) e 0 x Ro, 

Q = {(p>p') G 0 x 6: 3 (k,r,p) € N x i? 0 x M 9 
p € C'J RM (fc,r,p), 

3 {k, r,p')€NxR 0 xM5p' <E C^ RM (k, r, p'), 
start 1 * (p') > end p (p) 

-dp" e 0 3 start 1 * (p) < start 1 * (p") < start 1 * (p') 
start 1 * (p') - end p (p) > ri 4 }j => 
maxsepsat 1 ** (6, r) = Q 

Given a schedule 0 and a requirement r, maxsepsat 1 ** (0,r) 
returns the total count of pairs of consecutive prototype-event 
instantiations for requirement r in 0 that are separated by 
more than the maximum allowed separation r 44 . 


Definition 75: violations MINSEP * : 0 — > 1 3 
0e&=> violations MTNSEP * (0) = 

l+|i 2 o| 1 minsepsat 1 ** (0, r) 

j-e.Ro 

Given a schedule 0, violations MINSEP * (6) returns the value 1 
plus the ratio, averaged over all requirements r, of the num- 
ber of pairs of prototype-event instantiations for requirement 
r in 6 that are separated by less than the minimum allowed 
separation n 3 to the number of elements (prototype-event in- 
stantiations) in the schedule. This metric will be exactly 1 for 
a perfect schedule and a greater value otherwise. 

Definition 76: vioIations MAXSEP * : 0 -> R 9 
6 6 0 => violations MAXSEP * (9) = 

l+|i 2 o| 1 Y2 maxsepsat 1 *’ (0, r) 

reRo 

Given a schedule 0, violations MAXSEP * (0) returns a value 
equal to 1 plus the ratio, averaged over all requirements 
r, of the number of pairs of prototype-event instantiations 
for requirement r in 0 that are separated by more than the 
minimum allowed separation r 44 to the number of elements 
(prototype-event instantiations) in the schedule. This metric 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 

Definition 77: schedolpairs : 0 -> codomain (C^ 1 ™) 2 3 

0e0=r- 

schedolpairs (0) = j (p,p r ) €0x0: 

start 1 * (p) < start 1 * (p') < end p (p)j 

Given a schedule 6 , schedolpairs(0) returns a set of overlap- 
ping pairs of members of 0 so that not both (p,p') and (p' , p) 
belong to the set and (p,p) does not belong to the set. 

Definition 78: interf* : 0 — > R 3 W0 € 0, 

Q = jz: r = (n,...,nr), 

r' = (r- r' 17 ) € Ro, k, k' € N, 

/r is an element of the sequence M type (r), 
pi is an element of the sequence M^ w {r'), 
k < len(r 3 ), k' < len(r 3 ), 

P G Crfrr.g),?' G C PRM (fc',r',//), 

(p,p') € schedolpairs (0), 

n, n! € N, n < len(r 3 [fc]), n' < len(r 3 [fc']), 

A = (r2, A 2 , . . . , A 7 ), A' = (rg, A 2 , . . . , A 7 ) € Lq, 
(A, •) = r 3 [k\[n\, 

(A', = r' 3 [k'][n'], 

p[n] = (t,a = (oi, . . . ,a 4 ), s,d), 

P'W] = ( t',a ’ = (a , 1 ,...,a , i ),s',d'), 
e € I(ai,a[, A, A'), 

e fl [t + s, t + s + d] n [t' + s' ,t' + s' + d'] 7^ 0, 
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x = =>• 

interf 1 *^) = 1 + |0| 1 |Q| 

interf* returns the value 1 plus an integer representing the in- 
stances where interference exists between two active links in 
a pair of prototype-event instantiations in the schedule, aver- 
aged over all elements (prototype-event instantiations) in the 
schedule. This metric will be exactly 1 for a perfect sched- 
ule and a greater value otherwise. 

Definition 79: endpts : 0 -9 p(N) 9 8 G 0 =>■ 
endpts(0) = |a :: r = (n, . . . ,n 7 ) G Rq, 
k G N, k < len(rs), 

(•> A*) £ -^type(f)> 

p G C^ik, r, p),p G 0, (t, a, s, d) € p, 

[a; = t + sVa:=f-|-s + d]| 

The function endpts(0) returns the set of all of the endpoints 
of all service instantiations in all prototype-event instantia- 
tions in 8. 


Definition 80: endpts seq : 0 — > S*(N) 9 V0 G 0, 

£ G endpts(0)se q 

4 € S*(endpts(d)) and 

ieN,i+l< len(£) =*> £[*] < £[i + 1] 

The function endpts seq (d) converts the set endpts(0) into an 
increasing sequence of times on the timeline. 


Definition 81: resourceusage : 0 x N -> 

p(N xRqxMxN 3 xL 0 x A 0 ) 9 

8 G 0,i G N, 

* + 1 < endpts (#) | , 

(k,r = 6N x R 0 x M, 

p G C^ RM (k,r,p),p G 8, 

n G N, n < len(rs[fc]), 

r 3 [fc][n] = (A= (r 2 ,A 2 ,...,A 7 ), •,*,•,•), 

(t, a,s,d ) GNx Ao x N 2 , 

p[n] = ( t,a,s,d ), 

£ = [endpts^ (0)[i] l endpts ieq (0)[i+ 1]], 
C n [(t + s), (t + S + d)] 7 ^ 0 =r- 
(, k , r, p, n, £“,£+, A, a) 6 resourceusage(0, i) 


Given a schedule 9 and an index i into the list of endpoints of 
all the service instantiations in 8, resourceusage (8, i ) returns 
a set of 8-tuples containing values representing the resources 
used during the interval starting at the time endpts^ [«]. 

Definition 82: k sn : {“S”,“K”,“Kl”,“K2”}x 
{“MA”,“SA”} x {“FWD”,“RTN”} -9 N 9 
(b, c, d) G {“S”,“K”,“K1”,“K2”} x (“MA”,“SA”}x 
{“FWD”,“RTN”} 


Case 

K(a, c, d) 

(1) c =“SA” and d = • 

2 

(2) c =“MA” and d =“FWD” 

1 

(3) c =“MA” and d =“RTN” 

5 


Table 1. Space Network Forward and Re- 
turn Link constraints from the Space Network 
Users’ Guide (SNUG) 


Case 

«/(a, c, d) 

(1) c =“SA” and d = • 

4 

(2) c =“MA” and d =“FWD” 

2 

(3) c =“MA” and d =“RTN’ 

20 


Table 2. Ground Network Forward and Return 
Link constraints 


k sn (6, c, d) = 0, except as shown in Table 1 

k sn returns the constraints on combinations of Space Net- 
work resource usage in any schedule. 

Table 1 states the station constraints that are provided as 
input to the scheduling system. For example, for any TDRS, 
there can be only one MAF, only five MAR, only two SSAF, 
only two SSAR, only two KSAF, and only two KSAR[1 8]. 

Definition 83: 

k gn : {“S”,“K”,“K1”,“K2”} x (“MA”,“SA”}x 

(“FWD”,“RTN”} ->N9 

( b,c,d ) G {“S”,“K”,“K1”,“K2”} x {“MA”,“SA”}x 

(“FWD”,“RTN”} =>• 

k gn (6, c, d) = 0, except as shown in Table 2 

k gn returns the constraints on combinations of Ground Net- 
work resource usage in any schedule. 

Table 2 states the ground terminal constraints that are pro- 
vided as input to the scheduling system. For example, for 
WSC (White Sands Complex), there can be only two MAF, 
only 20 MAR, only four SSAF, only four SSAR, only four 
KSAF, and only four KSAR. However, this is a simplification 
that would have to be dealt with, both in a more realistic for- 
mulation of the SN scheduling problem and in a full specifi- 
cation of the problem solution (i.e., as a schedule-generation 
algorithm to be implemented in a fielded, production-level 
scheduling system). The actual SA constraints are subject to 
additional rales that likewise would need to be included in 
the specification for a fielded scheduling system. For exam- 
ple, in the SNUG, Note 5 in Figure 3-1 “Telecommunications 
Services for each SGLT” [18] states the following: 

The SN can simultaneously support S-band and 


25 





4.3 Domain- Specific Definitions 


4 DEFINITIONS 


K-band (either Ku or Ka for TORS spacecraft 
F 8 through F10) forward and/or return services 
through one SA antenna to the same ephemeris. 

Definition 84: violations|^> iI,PTS : 

0 x N x {“S”,“K”,“K1”,“K2”} x 

{“MA” “SA”} x {“FWD” “RTN”} ->N3 

^ e0,i6l,i + l< |endpts(0)|, 

(b, c, d) G {“S”,“K”,“K1”,“K2”} x 

(“MA” “SA”} x (“FWD”, “RTN”}, 

Q = {a; : x = A = (Ai, ... , A 7 ), •) G 

resourceusage(#, i ) , 

A3 = b, A4 = c, A5 = d, | , 

WSN = I <5 1 - K SN {b, c, d) =>- 
violations^™ DPTS (6, i, b, c, d) = max({ 0 , «sn}) 

The function violations|!£ E i5 IDPTS (0, i, b, c, d) returns the 
count of violations of the constraints on usage of Space Net- 
work resource ( 6 , c, d) in the interval i in 9. 

Definition 85: violations™(™ l,,xrs : 

0 x N x (“S”,“K”,“K1”,“K2”} x 

(“MA” “SA”} x (“FWD”, “RTN”} -> N 9 

6>G0,*GN,* + 1< |endpts(0)|, 

( b,c,d ) G {“S”,“K”“Kl”“K2”}x 

(“MA”,“SA”} x {“FWD” “RTN”}, 

Q = ja; : x A = (Ai, ... , A 7 ), •) G 

resourceusage($, i ) , 

A3 A4 C, Ag d, ^ , 

^GN = |Q| - K™(b,c,d) => 
violations^c".n NDIMS (^1 h b, c, d) = max({ 0 , ^gn}) 

The function violationsB^j£® PTS (0,/, b, c, d) returns the 
count of violations of the constraints on usage of Ground 
Network resource ( b , c, d) in the interval i in 6. 

Definition 86: violations SN " ENDPTS : 0 x N -> R 9 

(9, i) G 0 x N, h = |endpts(d) | — 1 =4- 

violations SN ' ENDPTS (d,i) = 

hr 1 E violationsB N { : E ^ ,DPTS ( 6 <, i, 6 , c, d) 

(b ,c, d) Edom ( rc SN ) 

The function violations SNENDPTS (d, i) returns the count of 
violations of the constraints on usage of all Space Network 
resources in the interval i in 9, averaged by the number of el- 
ements in endpts(d) less 1 . 

Definition 87: violations™ ENDPTS : 0 xN-»K 3 
(8, i) e0xN,/i = |endpts(0) | — 1 => 

violations™" ENDPTS (#, /) = 


h 1 E violationSn.c'^ ,DPls {9, i, 6 , c, d) 

(6,c,d)Gdom(K GN ) 

violations GN ' ENDPTS (6, i ) returns the count of violations of 
the constraints on usage of all Ground Network resources in 
the interval i in 9, averaged by the number of elements in 
endpts(d) less 1. 

Definition 88: violations SN : 0 — > R 3 
9 G 0 => violations SN (d) = 

1 + 1 9 1 _1 £ violations SN ' ENDFrs ( 9 , i) 

iG N 

i+l< |endpts(0)| 

violations SN (0) returns a value equal to 1 plus the count of 
violations of the constraints on usage of all Space Network 
resources in 9, averaged over all elements (prototype-event 
instantiations) in the schedule. This metric will be exactly 1 
for a perfect schedule and a greater value otherwise. 

Definition 89: violations™ : 0 -> 1 9 
9 G 0 => violations™ (9) = 

1 + | . 9 1“ : 1 E violations™ ENDPTS (9, i) 

ie N 

i+l<|endpfa(0)| 

violations™ (9) returns a value equal to 1 plus the count of 
violations of the constraints on usage of all Ground Network 
resources in 9, averaged over all elements (prototype-event 
instantiations) in the schedule. This metric will be exactly 1 
for a perfect schedule and a greater value otherwise. 

Definition 90: 

usage STATION ' SA " ENDPTS : 0 x N x So -> N 3 
(9, i, s) G 0 x N x So, i + 1 < |endpts(0)|, 

Q=\x-.x= (•,•,*,•,*,•, A = (Ai,...,A 7 ), 

a = (oi, . . . , 04)) G resourceusage(0, /), 
ai = s, A 4 = 04 = “SA”|J => 
usage STATI ™' SA ' ENI)IMS (9, i, s) = |Q| 

Given a schedule 9, given an index i into the se- 
quence of endpoints in endpts seq (d), and given a sta- 
tion s, usage STATI ™' SA ' ENDPTS (d, i, s) returns the demand 
for SA antenna support on s. 

Definition 91: 

violations STATI ™" SA ' ENDPTS :0xNxS o ->N3 

(9,i, s) G 0 x N x S 0 , 

vsa = usage STA ™ N " SA " ENDPTS (d, i, s ) - 6 'q A (s) => 
violations STA ™ N " SA ' ENDPTS (d, i, s) = max({0,r; SA }) 

violations STATI ™" SA ' ENDPTS (9 , i, s ) returns the count of vio- 
lations of the constraints on usage of SA antennas on station 
s in the ith interval in 9. 
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Definition 92: violations SAENDPTS :0xN->l3 
(^t)e0x!f,li = |endpts(#) | — 1 =>■ 

violations SAENDPTS ((9,*) = 

h- 1 £ yiolations STATIONSAENDPTS (^i, s ) 

8&Sq 

violations 8A ' ENDPT8 (#, i) returns the count of violations of 
the constraints on usage of SA antennas in the ith interval in 
6, averaged by the total number of elements in endpts($) less 
1. 

Definition 93: violations SA : 0 -> R 9 
8 G Q => violations 84 (#) = 

1 + M 1 £ violations SA ' ENI>PTS (#,i) 

<€N 

4+l<|cndpts(0)| 

violations 84 (#) returns a value equal to 1 plus the count of 
violations of the constraints on usage of SA antennas in 8, 
averaged over all elements (prototype-event instantiations) 
in the schedule. This metric will be exactly 1 for a perfect 
schedule and a greater value otherwise. 

Definition 94: stnsw PEI :0xNx R. (] x M —> Z + 3 
V(8,k,r = (n, . . . ,rn),p ) € 0 x N x R 0 x M, 
if P e C’o RM (fc,r, p), 
if p e 0, and 

Q = {a;: 3i,j <= N,3A € L 0 9 
i,j < len(r 3 [fc]),i ^ j, 
r 3 [fc][*] = (A, •,*,*, •), 
r3 NL j] = (A, 

p[i\ = {t,a= (oi, . . . ,a 4 ), s, d), 
p\j] = (t, a' = (ai, . . . , oi), s', d'), 
s + d< s ' , 
ai &i, 

[m € N, m < len(r 3 [fc]), 
m ^ i,m ^ j, 

p[m] = (t, a* = (a*,..., a^), s*,d*), 
r 3 [fc][m] = (A, •, •, •, •)] => s' < s*, and 

x = (i,j, A) j, then 
stnsw PE1 (8,k,r, p) = \Q\ 

stnsw™ 3 (0, k, r, p) returns the number of station switches 
that occur in the prototype-event instantiation p identified by 
(, k , r, p) in schedule 8. 

In this disclosure, for the metric stnsw PEI , a station switch 
is said to occur if, for a prototype-event instantiation p iden- 
tified by (k,r = (n, . . . ,rn),p), there are two services 
r 3 [fc][i] = (A, •,*,•,•) and r 3 [k]\j\ = (A, •,*,*,•), i,j € 
N ,i,j < len(r 3 [/c]), * ^ j such that if p[i] = ( t,a = 
(ffli) ■ • • i a 4 ,), s,d) and p\j\ = ( t,a ' = (a[, . . . ,a' 4 ),s' ,d'), 
and s + d < s', then ai a[ (i.e., the station providing 
the link service changes from the earlier service instantiation 


to the later), and if m G N, m < len(r 3 [fc]),m ^ ^ 

j,p[m] = ( t,a = (a 1 ',...,a* 4 ),s*,d*), and r 3 [fe][m] = 
(A, •, •, •, •), then s' < s*. Other possible definitions of “sta- 
tion switch” may be substituted for the one given above or 
may be included as additional metrics. 

Definition 95: vioIations STNSW : 0 -> 1 9 
6 € 0 =► violations STNSW (<9) = 

1+|0| 1 £ stnsw PE1 (8,k,r,p) 

r=(r, r 17 )£R 0 

fcGN3fc<len(r3) 

violations 8TN8w (8) returns a value equal to 1 plus the num- 
ber of station switches that occur totaled for all prototype- 
event instantiations in schedule 8, averaged over all elements 
(prototype-event instantiations) in the schedule. This metric 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 

Definition 96: rtndatarate COMBINED : 0 x N -> N 9 

(S,t)g0xN,i + l< |endpts(0) | =>■ 

rtndatarate COMBINED (0, i) = 

£ ^7 

A=(Ai A7),«)Gresonrcensage(e,i) 

a 5 =“rtn” 

rtndatarate COMBINED (0, i) returns, for the interval indexed 
by i in schedule 8, the combined data rate in all the active 
“RTN” links. 

Definition 97: violation RTNRATE : 0 x N -> N 9 

(S,i)g0xN,i + l< |endpts(0) | , 

x = rtndatarate COMB1NED (0, i) 

[x > MAXALLOWEDRTNRATE =>• v = 1] , 

[x < MAXALLOWEDRTNRATE = 0] 1 => 

violation RTNR4 ™(0, i) = v 

Given a schedule 8 and an index i into the sequence of 
endpoints in endpts^ (8) , violation 8 ™* 4 ™ (8, i ) returns the 
value 1 if the total of the data-rate values in all of the ac- 
tive “RTN” links during the interval in 8 whose left end- 
point is indexed by i exceeds the value of the fixed param- 
eter MAXALLOWEDRTNRATE, and returns 0 otherwise. 

Definition 98: violations RTNRATE : 0 -> I 9 
8 G @,h= endpts(0) | — 1 => 
violations RTNRATE (8) = 

1 + /i -1 £ violation 8 ™ 84 ™^, i) 

t£N 

i+l< |endpts(0) | 

violations 8111184 ™ (8) returns a value equal to 1 plus the 
number of intervals in schedule 8 in which a data-rate vio- 
lation exists, averaged over the total number of intervals in 
8. This metric will be exactly 1 for a perfect schedule and a 
greater value otherwise. 
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Definition 99: satisfied PEI :0xNxJJ o xM->i3 
[0, k,r = (n,. . - ,r 17 ),p) e Q xN x Rq x M, 
p € C'q RM (A;, r, p),p e 8 , x G M, 

Q = |(rf,e) 6 N 2 : n 6 M, 

n < len(r 3 [fc], (•, •, »,d) = p[n], 

(A= (Ai,...,A 7 ), •,*,•,•) = r 3 [fc][n], 

A 5 = “RTN”, e = A 7 |, 

x = ed > 0 =>■ 

(d,e)eQ 

satisfied™ 1 (0, k,r,p) = 1 — 1 1 — x/rio \ 

satisfied™ 1 (0, k, r, p) returns the total data bits returned to 
Earth during the prototype-event instantiation identified by 
(k, r, p) in schedule 0, divided by the desired volume ri 0 
of data returned in the instantiation of any prototype event 
scheduled to satisfy r. This metric will be exactly 1 when the 
total number of returned data bits equals the desired quan- 
tity, and will be a nonnegative number less than 1 otherwise. 

Definition 100: satisfied*: 0 x Rq -> M 9 

( 8 , r = (ri,...,n 7 )) € 0 x Rq, 

Q = jp: 3 (k,p) e N x M 9 
p€C$ SM (k,r,p),p& 8 } 
h = max({l, |Q|}) => 
satisfied* (0, r) = 

h~ l satisfied™ 1 ( 8 , k, r , p) 

fc£N,k <len(r 3 ) 

(• »^*) G A/jypc (r) 

satisfied* (0,r) returns, for requirement r, the ratio repre- 
senting the satisfaction of the requirement ri 0 for total data 
bits returned by all the prototype-event instantiations for re- 
quirement r in schedule 8 , averaged over all such prototype- 
event instantiations. The value returned is a nonnegative 
number not exceeding 1. The metric will have the value 1 
if the schedule is perfect. 

Definition 101: satisfied* :0— ^Ii90€0=^ 
satisfied* ( 8 ) = 2 — f] <f‘(t/(r))satisfied*(0, r) 

rERo 

satisfied* ( 8 ) returns, for all requirements r, a value equal to 
2 minus the product of all of the user-priority-weighted ratios 
representing the satisfaction of the data-retum requirements 
rio for total data bits returned to Earth by all the prototype- 
event instantiations for requirement r in schedule 8 . This 
metric corresponds to the overall degree to which the sched- 
ule satisfies all data-retum requirements. The value returned 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 

Definition 102: V) e {0, . . . , 11}, 3j : 0^l3Se0=> 


Jo(0) = violations STNSW (0), 

Ji ( 8 ) = violations SKIP *(0), 
h{ 8 ) = violations SKTPFILL *(0), 

J 3 (0) = violations MINSEP *(0), 

34 ,( 8 ) = violations MAXSEP *(0), 

J 5 (0) = violations SN (0), 

Je(0) = violations GN (0), 

J 7 (0) = vioIations SA (0), 

3 s( 8 ) = violations STNSW (0), 

Jg(0) = violations*™*^* (0), 

J 1O (0) = interf* ( 8 ), and 
Ju(0) = satisfied* ( 8 ) 

Definition 103: fitness :0->R90e0=>- 

fitness(0) = n J j( 8 ) 

je{o,...,n} 

This is the “fitness function”, which returns 1 for a perfect 
schedule and larger values for schedules that are not so good. 

Note the perhaps unexpected numerical aspect of the fit- 
ness function defined above, by which a better schedule has 
a lower numerical value than a worse schedule. The best pos- 
sible schedule is not less than, but indeed is indistinguishable 
from, unity. 

We now define a series of functions that provide the 
genetic mutation and crossover transformations needed to 
evolve the working population during the operation of the 
schedule-generation algorithm (see Section 5 (page 32)). 

Definition 104: mdpei: 0 — > N x Rq x M 3 

8 e 0,r = mdmember(f? 0 ), 
j = mdint(0,len(M (ype (r)) - 1 ),p = M type (r)\j\, 
k = mdint(0, len(r 3 ) — 1), 

peC$* M (k,r,p),pe 8 => 
mdpei (0) = (k,r,p) 

Given a schedule 8 , mdpei(0) returns a parameter tuple 
(k, r, p) that corresponds randomly to a prototype-event in- 
stantiation belonging to 8. 

Definition 105: mdsvc: 0 N x ii 0 x M x N 9 

8 e 0, (k, r, p) = mdpei(0), 

n = mdint(0, len(r 3 [fc]) — 1) => 
mdsvc(0) = (k, r, p, n) 

Given a schedule 8 , mdsvc(0) returns a parameter tu- 
ple (k, r, p, n) that corresponds randomly to a service in a 
prototype-event instantiation belonging to 8. 

Definition 106: 

modsvc :0xNxi? o xMxN 2 x J 4oxN 2 ->03 
( 8 , k, r, p, n, t, a, s, d) € 

©xNxfloxMxP^xAoxN 2 , 
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8' G 0, 

p G C£ RM (fc,r,/i),p G 8, 

j/gCH^,Ap'g«', 

0\w=a'\oa 

b G N, j < len (p),j ± n\ =>• pbl = P'b1> and 
p'[n] — (t,a,s,d) => 
modsvc(d, fc, r, /x, n, t, a, s, d ) = d' 

Given the tuple ( 0 , k, r, p, n , t, a, s, d), the function modsvc 
returns a schedule identical to 8 except with the service in- 
stantiation indexed by n in a prototype-event instantiation be- 
longing to 8 (and identified by the tuple ( k , r, p)) replaced 
with a service instantiation (t, a, s, d). 

Definition 107: slipsvc :0->09 
6, k, r, p, n, t , a, s new , d) G 

0 x N x R 0 x M x N 2 x A 0 x N 2 , 

( k,r,p,n ) = mdsvc(d), 
p G C^ M {k,r, p),p G 8,p[n] = ( t,a,s,d ), 
p v = (pX, . . . , p%) G M, 
p v G V(ai,r 2 ) 

(s*,d*)G N 2 , 

(t, a, s*, d*) = k, n, p, p y , and 

s new = mdint(s*, (s* + d* - d)) => 
slipsvc(d) = modsvc(d, fc, r, p, n, t, a , s„ew, d) 

Given a schedule 0, slipsvc(d) returns a schedule identical to 
8 except with a randomly selected service instantiation in a 
prototype-event instantiation belonging to 8 replaced with a 
service instantiation resulting from slipping the original ser- 
vice instantiation to the left or right by an allowed random 
amount. 

Definition 108: chngsvcdur: 0 — > 0 3 

(8, k, r, p) G 0 x N x Rq x M, 

(k, r, p, n) = mdsvc(d), 
p G Cg >RM (fc, r, p),p G 8,p[n] = ( t,a,s,d ), 

M V = gM, 

/x V G y(ai,r 2 ), 

(s*,d*)eN 2 , 

(t, a, s*, d*) = Yj^r, k, n, p, p Y ), 

(A, d”,d+) Gf 0 x N 4 , 

r 3 [fc][n] = (A,»,*,d“,d+), 
dmax = min({d*, d + }), and 
dnew = rndint(d , dmax) ^ 
chngsvcdur(d) = modsvc(d, k, r, p, n, t, a, s, d new ) 

Given a schedule 8, chngsvcdur (8) returns a schedule iden- 
tical to 8 except with a randomly selected service instantia- 
tion in a prototype-event instantiation belonging to 8 replaced 


with a service instantiation resulting from changing the du- 
ration of the original service instantiation by an allowed ran- 
dom amount. 

Definition 109: chngsvcsta : 0 -> 0 3 

(8, k, r, p) G 0 x N x Rq x M, 

(k, r, p, n) = mdsvc(d), 
p G C'o RM (fe, r, p),p G 8,p[n] = ( t,a,s,d ), 
f G = mdint(0, |_A 0 | - 1), 

j G N,j < len(£), £b] =a,i ± j, 
a' = £[i],oi ^ ai,a' 3 = a 3 ,a' 4 = a 4 , 

M V = G M, 

p Y G V{a u r 2 ), 

(s’/jGf, 

(i, a', s*, d*) = Yj^r, k, n, p, p v ), and 
[(t + s), (t + s + d)] C [(t + s ), (t + s + d )] =>■ 
chngsvcsta (0) = modsvc(d, fc, r, p, n , t, a', s, d) 

Given a schedule 0, chngsvcsta(d) returns a schedule iden- 
tical to 8 except with a randomly selected service instan- 
tiation in a prototype-event instantiation belonging to 8 re- 
placed with a service instantiation resulting from changing 
the support antenna of the original service instantiation to a 
randomly selected allowed antenna on a different station. 

Definition 110: chngsvcant: 0 403 

(8, k, r, p) G 0 x N x Ro x M, 

( k,r,p,n ) = mdsvc(d), 
p G C$™(k, r, p),p G 8,p[n\ = (t, a, s, d), 

£ G E(A))b = rndint(0, |^ 0 | - 1), 
j G N,j < len(^),^b] = a,i ± j, 

a ! = = 01,03 = 03,04 = 04 =$> 

chngsvcant(d) = modsvc(d, k, r, p, n, t, a', s, d) 

Given a schedule 8, chngsvcant(d) returns a schedule iden- 
tical to 8 except with a randomly selected service instanti- 
ation in a prototype-event instantiation belonging to 8 re- 
placed with a service instantiation resulting from changing 
the support antenna of the original service instantiation to a 
randomly selected allowed antenna on the same station. 

Definition 111: replacepei: 0 403 

{8, 8', k, k', r,p)e0 2 xN 2 xRoxM, 

( k,r,p ) = mdpei(d), 
k' = mdint(0,len(r 3 ) — l),k' ^ k, 
p G C'o RM (/c,r, p),p G 8, 
p'GC RRM (fc',r,/x),p'Gd', 

fl\to = *W}]=> 

replacepei(d) = 8' 
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Given a schedule 6. replacepei(0) returns a schedule identi- 
cal to 6 except a randomly selected prototype-event instan- 
tiation belonging to 6 is replaced with an instantiation of a 
randomly selected different prototype event for the same re- 
quirement and for the same mission event relative to which 
the original prototype event was instantiated. 

Definition 112: cutexcesspei :0->09 
(6, 0', k, k', r, p) E 0 2 x N 2 x Rq x M, 
violations SKIPFILL * (0) > 0, 

Q = jp: (k, i, r, p) E N 2 x Rq x M, 

i < len(M type (r)), ~>i E 3 (r. 0) , 
p = M type (r)[i\,p E C'o RM ( fc > r >A‘)>P E flj] => 

cutexcesspei (0) = 0\Q 

Given a schedule 0, cutexcesspei($) returns a schedule iden- 
tical to 0 except all excess prototype-event instantiations be- 
longing to 0 excised. Excess prototype-event instantiations 
are those that cause the function violations SKIPFILL * (see 
Definition 70) to return a value greater than 0. 

Definition 113: swappei : 0 2 -3 0 2 3 

(0, 0', e, e', k, k', r, p) E 0 4 x N 2 x Rq x M, 

0 O' , ( k , r, p) = mdpei(0), 

k! — mdint(0,len(r 3 ) - 1), k! ^ k, 
pEC$* M (k,r,p),pE0, 
p' EC™ M (k',r,p),p' E 6', 
e = 0\{p} U {p 1 }, 

e' = 9'\{p'}U{p}] => 
swappei(0,0') = (e, e') 

Given a pair (8, 6') of schedules, swappei (#, 0') returns a 
pair (e, e') of schedules identical to ( 6,6 ') except a ran- 
domly selected prototype-event instantiation belonging to 6 
is swapped in 6' with an instantiation of a randomly selected 
different prototype event for the same requirement and for 
the same mission event relative to which the original proto- 
type event was instantiated. 

Definition 114: swappeionr: 0 2 -> 0 2 3 

{6,6',e,e')zQ i ,6^6', 
r = mdmember(iio), 

Q = l^x: x E 8, (k,r, p) EN x R 0 x M, 

x € j 9 

( k , r, p) € N x Rq x M, x E r, p), 

y G r, //),£ G Q,y G q] ^x = y, 

B = jcc : x G 6', ( k , r, p) G N x Rq x M, 
x G C'^ RM (fc,r,/r)| 9 


4 DEFINITIONS 

(. k , r, p) G N x R 0 x M, x G C^ RM (k, r, p), 

y G C^ KM (k,r,p),x G B,y G B =>x = y, 
e = ( 6\Q ) U B, 
e' = (6'\B) U Q] =► 
swappeionr($, 6') = (e, e') 

Given a schedule pair (0, 6'), swappeionr returns a schedule 
pair (e, e') identical to (0, 0') except that for a randomly se- 
lected requirement r all prototype-event instantiations for r 
belonging to 6 are swapped with all prototype-event instanti- 
ations for r belonging to 0' . 

Definition 115: swappeionu: 0 2 — > 0 2 9 

\0,ff,e,ef) € 0 4 , 0 ^ 0 ', 

u = mdmember(f/o), 

Q = jz: (k,r = (n, . . .,m),p) G N x Rq x M, 
r? = u,x E Co SM (k, r, p), x G 0 j 3 
(k, r, p) G N x Rq x M, x G C^{k, r , /r), 
y £ Cft RM (fc, r, p), x G Q, y G q] =>■ a: = y, 

J3 = | a;: (fc,r = (n, . . . ,ri 7 ),/z) G N x E 0 x M, 
r 2 = u, x E CQ KM (k, r,p),xE 6'\ 3 
(fc, r, /i) G N x i? 0 x M, ® G Cg™(fc, r, p), 

V G CQ KM (k,r, p), x E B,y E B x = y, 
e = (0\Q) U jB, 
e' = (6'\B) UQ]=> 
swappeionu(0, 0') = (e, e') 

Given a schedule pair (6, 6'), swappeionu returns a schedule 
pair (e, e') identical to (6, 6') except that for a randomly se- 
lected user u all prototype-event instantiations for u belong- 
ing to 6 are swapped with all prototype-event instantiations 
for r belonging to 6'. 

Definition 116: swapearlypeionr : 0 2 -> 0 2 3 

(8,0',e,e') Ee i ,0^0', 

r = rndmember(J? 0 ),len(Mtyp e (r)) > 1, 
j = mdint(0,len(M type (r)) - 2), 

Q = jz: x E 6, 

(i, k,r = {r r 17 ),p) G N 2 x R 0 x M, 
i<j,p = M Vyvt {r)\i\,xEC^ BM {k,r,p)^ 3 

( k , r, p) E N x R 0 x M,x E Cq RM (fc, r, p), 
y E Co aM (k,r,p),x £ Q,y £ q] =>x = y, 

B = ja;: x E 6' 
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(i, k, r = (n, . . . , rn),p) G N 2 x R 0 x M, 
i<j,p = M ty pe(r)[i], x G C£ RM (fc, r, /x)} 9 

(A;, r, p) G N x iJ 0 x M, x G r, /x), 

V GC^ SM (k,r,fi),x G B,y gB =S> z = y, 
e = (0\Q) U B, 

e' = (0'\B)uQ => 

swapcarlypeionr(0, 0') = (e, e') 

Given a schedule pair (8, O') , swapearlypeionr returns a 
schedule pair (e, e') identical to (8, O') except that for a ran- 
domly selected requirement r and a randomly selected mis- 
sion event instance of type r 4 all prototype-event instantia- 
tions for r earlier than m belonging to 0 are swapped with 
all prototype-event instantiations for r earlier than m belong- 
ing to O'. 

Definition 117: swapmidpeionr : 0 2 -> 0 2 9 

(0,0',e,e') G0 4 ,O^' 

r = mdmember(ii 0 ),len(M t yp e (r)) > 2, 
i = mdint(0,len(M ly p e (r)) - 3), 
j = mdint(* + l,len(M type (r)) - 2), 

Q = jz: x G 0, 

(n, k, r = (n, . . . , ri 7 ), p) G N 2 x f? 0 x M, 
i < n < j, p = Mt,pe(r)[n], 

x € C'J RM (fc,r,/x)| 9 
(fc, r, /x) G N x fio x M, a G C'J RM (fc, r, /x), 

y e r,p),x € G qJ =>x = y, 

B=^x:xgO\ 

(n,k,r = (n, . . . ,ri 7 ),/x) G N 2 x f? 0 x M, 
i<n<j,p = Mu pe(r)[n], 
x G Cg RM (k,r, /x)| 9 

(fc, r, /x) G N x R 0 x M, x G C'J RM (fc, r, /x), 

y € C$ KM {k,r,p),x € B,y e B =>x = y, 
e = ( 0\Q ) U jB, 
e' = (0'\B) U Q => 
swapmidpeionr(d, 0') = (e, e') 

Given a schedule pair (0, O'), swapmidpeionr returns a 
schedule pair (e, e') identical to (0, O') except that for a ran- 
domly selected requirement r and two randomly se- 
lected mission event instances /x and p of type r 4 
all prototype-event instantiations for r inclusively be- 
tween /x and /x* belonging to 0 are swapped with all 


prototype-event instantiations for r earlier than m belong- 
ing to O'. 

Definition 118: 

mdsvcs: N 2 x R 0 x M -> p(N x A 0 x N 2 ) 9 
V(n, k,r = (r 1 ,...,r 17 ),p = {p u . . . ,/x 5 )) G 
N 2 x R 0 x M, 

(t p , a, s, d) G mdsvcs(n, k, r, /x) =>■ 

Mi = r 2 ,/x 2 = r 4 ,fc < len(r 3 ),n < len(r 3 [fc]), 
t p = tref (r,/x), 

|jQ = |(t p , a, s*, d*) gNxj4 0 xZxN: 

3/x v G M 9 ( t p ,a,s*,d *) G y r 1 Lx(t%M,/x,/x v )}, 
(t p ,a,s',d') = rndmember(Q), 

(•,s“,s + ,*,d+) = r 3 [fc][n], 

C = [s', (s' + d')] n [s _ , (s+ + d+] =>• 

s = mdint(C _ , (C + — d - )), 
d m ax = min({d+, (C + - s)}), 
d = mdint(d“, dmax) 

Given (n, fc, r, /x) , mdsvcs (n, fc, r, p) is a set of randomly se- 
lected service instantiations for service r 3 [fc][n] relative to 
mission event instantiation /x. 

Definition 119: mdpeis: N x J?o x M -> 
p(codomain(F 1 )) 9 

V(fc,r = (ri,...,n 7 ),/x= (/xi,...,/x 5 )) G 
N x Rq x M, 

£ G mdpeis(r, fc, /x) => 

Pi = r 2 ,p 2 = r 4 ,fe < len(r 3 ), 

£ is a sequence having len(r 3 [fc]) elements, and 

[n G N, n < len(£)] =>■ £[n] G mdsvcs(n, A:, r, /x) 

Given (fc, r, p), mdpeis (k, r, p) is a set of randomly selected 
prototype-event instantiations for prototype event r 3 [A:] rela- 
tive to mission event instantiation p. 

Definition 120: 0 RN d: N + -» p(0) 9 Vn G N + , 

3Q C 0 9 | Q | = n and 0 G Q => 

Vp G 0, 

3(k,r = (n,...,n 7 ),/x= (/xi,...,/x 5 )) G 
N x i?o x M 9 
Mi = r 2 ,P2 = r 4 , 
k = mdint(0,len(r 3 ) — 1), 

3* G N 9 

i < len(Mtype(r)) 9 

p = ‘l^type (r ) 1 ^skips (i’ , 0) [x]] , and 
P G mdpeis(A;, r, /x), 
and 0 rnd(^) = <3 

©RND(n) returns a set of n randomly generated schedules. 


31 



5.1 Specification of Optimal Schedule-Generation Algorithm 5 OPTIMAL SCHEDULE-GENERATION ALGORITHM 


5. Optimal Schedule-Generation 
Algorithm 

The definitions given in Section 4 (page 15) permit a pre- 
cise specification of an algorithm for generating optimal so- 
lutions for the NASA space-data communications schedul- 
ing problem. These definitions encompass functions for gen- 
erating random permissible solutions, creating mutations of 
members of the solution space, creating children of pairs of 
members of the solution space using the “genetic crossover” 
mechanism, and evaluating the fitness of members of the so- 
lution space. 

5.1. Specification of Optimal 

Schedule-Generation Algorithm 

Algorithm 1 (Optimal-Schedule Generation Algorithm): 

1. Assume given: 

(a) v G N + is the run time limit in units of seconds. 

(b) no G N + is the nominal working size of the pop- 
ulation at the beginning of each iteration of the 
algorithm. 

(c) IT = 0RNo(no), the initial, randomly selected 
population of schedules. 

(d) ip G N + , the number of steps in which new mem- 
bers of the population are generated in each iter- 
ation of the algorithm, i.e., the number of steps 
starting with step 4 and ending with step 15. 

(e) ae#,a tuple having ip elements 9 

i. Vj G {1, ■ ■ • , ip}, otj G N is the number of 
new candidate members to be added to the 
schedule population in step j + 4 in the al- 
gorithm. 

ii- E a i = n o- 

The sequence a consists of the values of the 
internal parameters of the algorithm. 

(f) 0 < r e R, a small value to represent a policy 
or judgment as to how close to perfect a sched- 
ule must be to be considered “good enough” to 
exit the algorithm, r normally would be set small 
enough to ensure that the algorithm always ran 
for the maximum allowed run time v. 

2. Let II' = 0. In each iteration of the algorithm, 11' will 
accumulate members to be added to the present popu- 
lation, from which combination the n 0 best schedules 
will be extracted to compose the next generation. 

3. V7T G II, let 7 r' = cutexcesspei(7r) and let II = 

(n\W)u{4 


4. Vj G {1, ..., ip}, randomly form Ilj c II 9 |llj| = 

aj. 

5. Vn G III, let 7 r' = slipsvc( 7 r), and let II' = II' U { 7 r'}. 

slipsvc (Definition 107) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

6 . V 7 T G n 2 , let 7 r' = chngsvcdur( 7 r), and let II' = II' U 

Wb 

chngsvcdur (Definition 1 08) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

7. V 7 T G n 3 , let 7 r' = chngsvcsta( 7 r), and let II' = II' U 

Wb 

chngsvcsta (Definition 109) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

8 . Vn G n 4 , let 7 r' = chngsvcant( 7 r), and let II' = II' U 

Wb 

chngsvcant (Definition 1 1 0) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

9. V 77 G II 5 , let 7 r' = replacepei( 7 r), and let II' = II' U 

K>- 

replacepei (Definition 111) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

10. Let Q = RND(|a 6 ,IIg) 9 ( 7 r, 0) G Q => - , ( 0 , 7 r) G 
Q. V(n,9) G Q, let ( 7 r',0') = swappei( 7 r, 9) and let 
n' = n'u{7r',6>'}. 

swappei (Definition 113) provides a “crossover” 
mechanism, where the “parents” (7r, 9) produce “off- 
spring” ( 77 ', 6'), parts of whose “genome” are from dif- 
ferent parents. Since two new solutions are added for 
each member of Q, a total of a 6 now solutions will be 
added. Similarly for each of the subsequent crossover 
steps below. 

11. Let Q = RND(|a: 7 , Ilf) 9 ( 77 , 6) G Q => “■(#, 77 ) G 
Q. V( 77 , 6) G Q, let ( 77 ', 6') = swappeionr( 77 , 9), and 
let n' = n' u { 77 ', 9'}. 

swappeionr (Definition 114) provides a “crossover” 
mechanism, where the “parents” ( 77 , 9) produce “off- 
spring” ( 77 ', 9'), parts of whose “genome” are from dif- 
ferent parents. 
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12. Let Q = RND(|oi8,IIg) 3 (n, 9) G Q => ~'{9,'ir) G 
Q. V(7r, 9) G Q, let (n',9') = swappeionu(7r, 9), and 
letir = n , U{7r',0'}. 

swappeionu (Definition 115) provides a “crossover” 
mechanism, where the “parents” (7r, 9) produce “off- 
spring” (7r', 9'), parts of whose “genome” are from dif- 
ferent parents. 

13. Let Q = RND(§ag,n2) 9 (7r, 9) G Q => ~ i {9,n) G 
Q. V(7r, 9) G Q, let 7r', 9' = swapearlypeionr(7r, 9), 
and let II' = II' U {7r', 9'}. 

swapearlypeionr (Definition 116) provides a 
“crossover” mechanism, where the “parents” (n,9) 
produce “offspring” (7r', 9'), parts of whose “genome” 
are from different parents. 

14. LetQ = RND(^Q!io, n^o) 3 (n,9) G Q => -<(9, n) G 
Q. V(7r, 9) G Q, let (n',9') = swapmidpeionr(7r, 9), 
and let II' = II' U {tt',0'}. 

swapmidpeionr (Definition 117) provides a 
“crossover” mechanism, where the “parents” (n,9) 
produce “offspring” (7r', 9'), parts of whose “genome” 
are from different parents. 

15. Let II" = 0 RN d(c*ii). Let II' = IT U II". 

This adds to the population at most an new mem- 
bers randomly selected from 0. 

16. Find lit c II U II' 3 |I3+ 1 = no and [iri G II+, 7T2 G 
(II U n')\nt] =>• fitness (7ri) < fitness ( 7 ^). Set II = 
lit and set II' = 0. 

17. Find 7riGll9£Gn=> fitness(^) > fitness (7ri). 7ri 
is the best member of II. If fitness (7Ti) < 1 + r or run 
time exceeds the limit v, go to step 1 8; otherwise, go to 
step 4. 

18. Output the best schedule 7r in II and exit. 

5.2. Schedule-Generation Algorithm: Internal 
Parameters 

Every successive generation of the population of schedules 
retains the best members of the previous generation com- 
bined with the new members added in the course of running 
the algorithm. The best member of a generation will be at 
least as fit as any member of the preceding generation, and 
consequently the fitness of the best member of each genera- 
tion will be a monotonic function of processing time (or the 
iteration count) (see Appendix 10 (page 40)). 

The algorithm as specified in the previous subsection does 
not stipulate the values of the internal parameters (repre- 
sented by the tuple a), and is silent on exactly how they 
should be chosen. There is no obvious relationship between 
the values selected and the performance that should be ex- 
pected of an implementation of the algorithm, although a 


method of finding a performance-optimizing set of choices 
for those values would be, potentially, highly advantageous. 

While any reasonable choices of the values of the above 
internal parameters would not prevent an implementation of 
the algorithm from reaching an optimal schedule for a given 
scheduling scenario, other choices might improve perfor- 
mance. In theory, while keeping constant (a) the seeds for 
the random-number generator, (b) the run time, and (c) the 
computing resources between runs, runs of the algorithm us- 
ing different choices of the values of the internal parameters 
may not find solutions with the same fitness; that is, some 
of the choices may be significantly more effective in find- 
ing optimal solutions with better fitness scores. It should be 
noted that these internal parameters (as represented by the tu- 
ple a) are not the only internal parameters that might be de- 
fined. For example, in the mutation steps 5 through 9, the 
number of places in the individuals’ genome that are modi- 
fied to produce new individuals could be adjusted to reveal 
the effect on the algorithm performance. 

If, for a given representative scheduling scenario, experi- 
mental runs of the implementation using a variety of choices 
for the internal-parameter values revealed a significant per- 
formance advantage for a particular choice, it would be valid, 
absent any further insight or data, to use that choice when 
running the implementation for other scheduling scenarios. 
The idea would be that a random or uninformed choice of the 
values is not likely to be better than a choice that has been 
found to be, for some representative scheduling scenario, the 
best one of a set of tested alternatives. 

Section 6 will specify an algorithm by which, for any 
given scheduling scenario, an optimal choice of the values for 
the internal parameters may be found, assuming such an op- 
timum exists (where “optimum” is again used in the sense in- 
dicated in Section 2.4.7 on page 13). The optimal choice, for 
any given scheduling scenario, would be one for which the 
algorithm’s performance could not be improved by means of 
a different choice, and the problem of finding such an opti- 
mum will hereinafter be referred to as the S # problem. 

In Section 7, we will propose an answer to the question 
of whether there is any reasonable way of relating schedul- 
ing scenarios to each other, where a “small” difference be- 
tween two scheduling scenarios would mean a correspond- 
ingly small difference in the optimal choice of the values 
for the internal parameters. We will seek to identify a solu- 
tion space for what we hereinafter call the S #|t problem — the 
final abstraction of the overall space data-communications 
scheduling problem — in which, for the implementation of 
the schedule-generation algorithm specified in Section 5.1, 
there exists an automated way to preprocess a given schedul- 
ing scenario to identify an optimal choice of the internal- 
parameter values. The remaining question of whether the per- 
formance of the overall system will be sensitive to differences 
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in the choice of the values of the internal parameters will be 
left to future work — likely entailing considerable computa- 
tional effort rather than theoretical analysis. 

6. Internal-Parameter Optimization: 
The S : Problem 

We will now take up the problem — which was denominated 
in the previous section as the S 5 problem — of finding an op- 
timal choice of the values of the schedule-generation algo- 
rithm’s internal parameters for a given scheduling scenario, 
thereby to optimize the schedule-generation algorithm for 
solving that scheduling scenario. 

6.1. The S** Problem: Introduction 

The internal parameter-optimization algorithm to be speci- 
fied in Section 6.3 will employ the same probabilistic search 
concepts presented in Section 5 in specifying the schedule- 
generation algorithm. As before, a population of solutions of 
the optimization problem will be evolved iteratively, and on 
each iteration the fitness of each member of the population 
will be determined. Not all, but just the fittest members of 
each generation will be allowed to survive into the next gen- 
eration. 

By definition, each member of the population is not a 
schedule (as in the schedule-generation algorithm itself), 
but rather a choice, e, of values of the internal parameters 
of the schedule-generation algorithm, and choice e will re- 
main fixed until the schedule-generation application program 
produces the best possible (optimal) schedule for the given 
scheduling scenario 7 . The fitness of each member of the 
evolving population of such choices e would be a numerical 
value representing the performance of the system. By defini- 
tion, the performance of the system (given the choice e) will 
be the fitness score of the best schedule that can be produced 
by the schedule-generation algorithm in a prescribed amount 
of processing time, with prescribed computing resources. 

During the entire iterative process of finding the best so- 
lution (i.e., the best choice, e, of values of the internal pa- 
rameters of the schedule-generation algorithm), the schedul- 
ing scenario will remain fixed, and at the end of the iterative 
process, the choice of the internal parameter values that re- 
sulted in the best performance is considered to be optimal. 

This abstracted search problem — the S s problem — will 
also have its own internal parameters, one of which is the pre- 
scribed amount of processing time allowed for the above it- 
erative process to produce a solution. Additional internal pa- 
rameters will be described below. While a subsidiary problem 
could be defined for the optimization of these parameters, it 
will be seen that this subsidiary problem would also have its 


own internal parameters to be optimized, leading to a sub- 
subsidiary problem of optimizing these internal parameters, 
and so on, without end — a kind of infinite regression. In the 
case of the NASA scheduling domain, it seems reasonable to 
ignore these subsidiary problems of optimizing internal pa- 
rameters of optimization problems, and instead, just make ju- 
dicious choices for the values of the internal parameters for 
the problem at hand (i.e., the S* problem), in the full expec- 
tation that the only disadvantage of doing so is that, to reach 
a solution that has the same fitness, processing time might be 
greater than it would have been with optimization. This posi- 
tion is further justifiable on the grounds that a one-time effort 
solving the S**** problem, as proposed in Section 7, can obvi- 
ate the need to pursue indefinitely a chain of S*- problem op- 
timizations using the above iterative process. 

6.2. The S : Problem: Definitions 

Definition 121 (Set of All Scheduling Scenarios): 
r = { 7 : 7 = (L# C L 0 , o** co,/»c I, 

P** C P,M# C M,P# C P 0 )} 9 
7 = (L#, 0 #,/#,P#,M#,P#) 6 r 

1. (n, . . . , ri 7 ) 6 P**, k G N, k < len(r 3 ), 

i G < len(r 3 [fc]) =► 
r3[k\[i] = (A, •,*,•,•) =» A 6 L*, 

2. (Ai, . . . , A 7 ) G => 3(ri, . . . , ri 7 ) G P 1 * 9 Ai = r 2 , 

3. (hi, . . . ,/ [i 5 )eM>7 3(n,. . . ,j*i 7 ) EP*3 

Mi = r 2 , 

4. ((s, s', A, A'), •) G /** 

3(/ii,...,M5) G V(s,Ai), 

3(m!> • • • 1 M 5 ) G VV.Ai), 

3(n,...,n 7 ) GP**, and 
3(ri,...,r' 17 ) eP* 9 
Ai = r 2 , Ai = r 2 . 

Mi = T 2 ,Mi = r' 2 

5. ( u , •) € P* 7 3(ri, . . . ,ri 7 ) G P** B u = r 2 

T is the set of all possible scheduling scenarios. 

Definition 122: fitness 1 * : T x R* x N + — ► M 5 
( 7 , e, £) G T x x N+ =>■ 
t is the run time allowed in units of seconds 
fitness 1 * ( 7 , e,t) = fitness(a-) is the fitness score of the 
best schedule, < 7 , produced by the schedule-generation algo- 
rithm running on the prescribed computing resources during 
a run interval of length equal to t seconds, for the schedul- 
ing scenario 7 and the choice e of the values of the internal 
parameters. (See Definition 103 (page 28) for the definition 
of the function fitness.) ip, recall, is the number of internal 
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parameters of the schedule-generation algorithm (see Algo- 
rithm 1, steps Id and le (page 32)). 

fitness** is the “fitness function” for the S** problem, which re- 
turns 1 for a perfect choice of the values of the internal pa- 
rameters of the schedule-generation algorithm and larger val- 
ues for choices that are not so good. 

6.3. Algorithm for Solving the S : Problem 

Algorithm 2 (S** Algorithm): 

1. Assume given: 

(a) 7 G T, a scheduling scenario. 

(b) v e N + , representing the allowed run time for the 
schedule-generation algorithm whenever it is ex- 
ecuted in the following steps. 

(c) i'** G N + , representing the allowed run time for 
performing iterations of the following steps in the 
search for the optimal choice of the values of the 
internal parameters of the schedule-generation al- 
gorithm. 

(d) ip* G N + , the number of steps in which new 
members of the population are generated in each 
iteration of the algorithm, i.e., the number of steps 
starting with step 3 and ending with step 7. 

(e) a* G 9 Vj G {1, . . . ,ip*},a*j is the num- 
ber of new candidate members to be added to the 
population in step j + 2 in the algorithm. Let 

n 0 = J2 °V 
je{i V*’} 

be the nominal working size of the population on 
each iteration of the algorithm. 

(f) ADDSLEVUT** € N + . This is the limit on the 
number of new members of the population that 
can be added to the population in any algorithm 
step. 

(g) n = RND(no,N^) 

Vj G {1, . . . , ip}, 9[j] < ADDSLEVUT**. 

2. Let IT = 0. In each iteration of the algorithm, IT will 
accumulate members to be added to the present popula- 
tion, from which combination the rig best members will 
be extracted to compose the next generation. 

3. Vj G {1 ,...,ip*}, randomly form 

rtf c n 9 |rtj | = a*. 

4. Let Q C III 9 \Q\= Oi[- 

V7T G Q, 

(a) let 7r' = 7 r, 


(b) let j = mdint({l, . . . , ip}), 

(c) let 7T '[j] = mdint({l, . . . , ADDSLEVUT**}), 

(d) let IT = IT U (tt'}. 

This is a “mutation” mechanism, where one element of 
an “organism’s” “genome” is modified to produce an 
offspring, which is then incorporated into IT. 

5. Let Q = RND(|q: 2! n^) ^ 

{it, 6) G Q => -i(#,7r) g Q. 

V(tt,9)gQ, 

(a) let n = mdint({l, . . . , ip}), 

(b) let 7r' = (tt[1 ], . . . ,ir[n],0[n + 1], . . . ,0[ip]), 

(c) let 9' = (0[1], . . . ,0[n], 7r[n + 1], . . . ,7r[i/>]), and 

(d) let IT = n , u{7r , ,6» , |. 


This is a “crossover” mechanism, where ran- 
domly many of the first elements of one “organism’s” 
“genome” are swapped with the same elements in an- 
other, resulting in two new members, which are then 
incorporated into II' . 

6. Let Q = RND(|a3, II3) 9 
(7r, 6) G Q => -i(9, ir) G Q. 

V(M)GQ, 

(a) let m, n 2 = mdint({l, . . . , ip}), ni ^ n 2 , 

(b) let 7r' = (7r[l],...,7r[ni], 

6[m + 1], . . . , 6[n 2 ] , 7r[n 2 + 1] , . . . , n[ip ]) , 

(c) let 9' = (9[l},...,9[m], 

7r[m + 1],. . . ,7r[n 2 ],0[n 2 + 1],. . . ,9[ip}), 

(d) and let II' = II' U {tt', 9'}. 


This is a “crossover” mechanism, where a random 
section of one “organism’s” “genome” is swapped with 
the same elements in another, resulting in two new 
members, which are then incorporated into 11'. 

7. Let Q C 9 9 G Q <s> 

Vj G (1, . . . , ip}, 9\j] < ADDSLEVUT**. 

Let IT = IT U RND(c4, Q). 

This adds a\ new members to the population ran- 
domly selected from PT’. 


8. Find 11+ C II U II' 9 


Inti 


n* 0 and 


7r g n+, # g (n u n')\ntj 


fitness** (7, 7r, v) < fitness** (7, 9, v). 
Let n = nt and II' = 0. 


9. Find 7r Gil 3 ( Gil =^ 

fitness** (7, C, v) > fitness** (7, 7 r, u). 

7r is the best member of II. 

10. If run-time exceeds z'**, output the best member 7r in II 
and exit; otherwise, go to step 3. 
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6.4. The S : Problem: Discussion 


As in the case of the schedule-generation algorithm itself, the 
population of solutions in the S* algorithm evolve (through 
the iterative steps of evolutionary search) with a monotonic 
improvement of the fitness score of the best member of the 
population toward some evidently limiting value. After some 
elapsed processing time, the run must be terminated and if 
the “knee” of the curve that represents the fitness of the best 
member of the population at the end of each iteration of the 
algorithm has been passed (see Section 10.2 (page 41)), then 
the best solution produced to that point is considered to be 
the optimal solution of the S* problem. 


The question might arise whether the evolving population 
of solutions might enter a runaway progression of the magni- 
tude of the values of the internal parameters in the execution 
of the above algorithm. It is quickly seen that this is not a con- 
cern: recall that each of the schedule-generation algorithm’s 
internal parameters represents the number of new schedules 
that will be allowed to be added to the population in some 
given step in each iteration of the algorithm. If a choice, e, 
of the values of the internal parameters included a very large 
value, the fitness of the best schedule produced within the 
schedule-generation algorithm’s run-time limit, v (a given in 
the S# algorithm), would be so bad that e likely would not be 
a member of the next generation. 


While no experimentation has been conducted to test it, 
the working hypothesis is that a diminishing return would re- 
sult from unbounded increases in the magnitude of any one 
of the internal parameters, other factors being constant. Ac- 
cording to this hypothesis, the performance achieved by the 
schedule-generation algorithm could be graphed as a func- 
tion of the value of an arbitrarily chosen one of the schedule- 
generation algorithm’s internal parameters, keeping other pa- 
rameters constant. This graph would have a point to the right 
of which the performance would worsen monotonically. The 
left-most such point could be found through applying the 
approaches described herein, but it could only be regarded 
as pseudo optimal since it would differ from the optimal 
solution that would be found when the other internal pa- 
rameters were unconstrained as well. Further analysis based 
on a model of the performance of the schedule-generation 
algorithm will be undertaken in Appendix A (Section 10 
(page 40)). 


7. A Further Abstraction: The 
Problem 

7.1. The S® Problem: Introduction 

To maximize the practicality of the technology disclosed 
herein, we now consider the S** problem (described briefly 
at the end of Section 5) — i.e., the problem of estimating an 
optimal choice of the values of the schedule-generation al- 
gorithm’s internal parameters so that it would not be neces- 
sary to perform the whole iterative (and computationally ex- 
pensive) process of solving the S* problem for every given 
new scheduling scenario. The S*® objective is to specify a 
means of easily estimating the best (i.e., optimal) choice of 
the schedule-generation algorithm’s internal parameters, us- 
ing (abstracted) information about the given scheduling sce- 
nario itself. 

No reason has been identified to suspect that the S #tt so- 
lution space is so ill-behaved as to render it impossible to 
find a reasonably accurate means of estimating an optimal 
choice of the values of the algorithm’s internal parameters 
for “points” in the solution space that are “between” other 
points for which the optimal choice has actually been calcu- 
lated (as a solution of the S # problem). However, the remain- 
der of this section (which describes an approach for solving 
the problem) may be regarded as somewhat speculative 
in the sense that (a) the author has performed only a lim- 
ited amount of relevant experimentation (as mentioned ear- 
lier in Section 2.4.6 (page 12)) and (b) the author’s proposed 
use of certain function-fitting (data regression) techniques, 
while plausible, is not accompanied by a thorough support- 
ing analysis. It is assumed that available computing platforms 
are adequate for solving the problem, and that some data- 
regression technology must suffice. 

To enable a data-regression approach, we make use of a 
scheduling-scenario characterization function: 

Definition 123 (Scheduling Scenario Characterization): 

A: T->N 8 97 = 

3{x u . . . ,x s ) G N 8 9 A ( 7 ) = (sci,. . . ,x 8 ) and 

1. Q = jr = (n, . . . , rn) G R$: r 4 = “NIL” j =>• 

xi = |< 2 | 

2. Q={r= (n, . . . ,r 17 ) G I?#: r 4 ^ “NIL”} =► 

X2 = \Q\ 

3. Q = jp: 3r = (n, . . . , rn) G H*, p is an element of 
the sequence 7-3 }■ CC 3 = | Q | 

4. Q = j/u: 3r = (n, . . . ,r 17 ) G R?, 
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P — {pi, ■ ■■ , g>5 ) € , g2 — ^4 ^ NIL ^ 

Xi = \Q\ 

5 . £5 = \ L ^\ 

6 . xq = | O * 

7. 2:7 = 1-7*1 

8 . x 8 = |P*| 

The function A produces an eight-dimensional “point” in 
N 8 , and, in relation to the problem, we assume that, for 
two scheduling scenarios 7 , 7 ', the ordinary Euclidean dis- 
tance 

(£ K -<) 2 

i=l 

between two points 

a = A ( 7 ) = (ax, ...,ag) eN 8 

a' = A(V) = (ai, . . . ,ag) e N 8 

representing the characterizations of 7 and 7 ', respectively, 
corresponds to (is commensurate with) the “distance” be- 
tween 7 and 7 '. 

7.2. Data-Regression Approach 

In the following paragraphs relative to solving the S #tt prob- 
lem, we assume the availability of a data-regression tech- 
nique such as evolutionary search (genetic algorithms), ar- 
tificial neural networks, Baysian networks, or support vector 
machines. 

Data regression [17, 26], a collection of well-studied 
methods of modeling multi-dimensional data interrela- 
tionships, is assumed to be viable as a means to derive a 
function for rapidly estimating, for an arbitrary schedul- 
ing scenario, the optimal choice of the values of the internal 
parameters of the schedule-generation algorithm. 

Data regression (or simply “regression”) is analogous to 
simple least-squares curve fitting with one independent scalar 
variable and one dependent scalar variable. Regression aims 
to fit a hypersurface to the set of known data points in the so- 
lution space. The best-fitting hypersurface can be expressed 
as a function that returns the dependent value given the in- 
dependent value. In the S #tt problem, the independent value 
would be the scheduling scenario (or, normally, the tuple 
that characterizes a scheduling scenario (i.e., the value re- 
turned by the function A (see Definition 123 (page 36))), 
and the dependent value would be the estimate of the op- 
timal choice of the values of the internal parameters of the 
schedule-generation algorithm. 

The essential, broad steps in applying a data-regression 
approach to the problem are as follows: 


Algorithm 3 (Algorithm for Optimal-Intemal-Parame- 
ters Estimation): 

Given: 

• A set T' C T of realistic/actual scheduling scenarios. 
The results of running an implementation of the present 
algorithm are highly dependent on the number and dis- 
tribution of these scenarios. If the accuracy of the es- 
timation function generated by this implementation is 
not deemed adequate, then T' would need to be re- 
vised and used in a fresh rerun. (Over the past three 
decades, a great many actual scheduling-problem sce- 
narios have been constructed and solved by the NASA 
space-data communications scheduling system. These 
scenarios would be a rich (and probably the most ap- 
propriate and reliable) source of data for building the 
set r.) 

Perform the following steps: 

1. For each 7 6 T', 

(a) solve the S # problem computationally, producing 
the optimal choice e of the values of the internal 
parameters of the schedule-generation algorithm, 

(b) compute the characterization c = A( 7 ). 

2. Retain the set Q of known (calculated) points (c, e), as 
obtained in step 1 . 

3. Randomly assign each member of the set Q to either of 
two (approximately equally numerous) disjoint sets: a 
training set Q train and a test set Qtest 9 

|Qtrain| |Qtest| G { 1)0,1} 

4. Perform data-regression using the training data set 
Q train, resulting in the determination of the intemal- 
parameters-estimation function that best fits the mem- 
bers of Q train- 

5. Using the test data set Qtcst. test and verify the estima- 
tion function derived in step 4. 

6 . If the derived function passes the test, let / designate 
the derived function (which represents the fitted hyper- 
surface) and exit indicating success. If the derived func- 
tion fails the test, then exit indicating failure, calling 
upon the user to alter the given set of actual/realistic 
problem scenarios (e.g., by increasing their number 
or variety) (noting that this alteration gives an altered 
problem) and rerun the algorithm. 

The derived function / estimates the optimal choice of 
the internal parameters of the schedule-generation algorithm, 
given any scheduling scenario. This function can be incor- 
porated into a fielded scheduling system to maximize overall 
performance, and can be used as specified in Section 7.3. 
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7.3. Operational Use of Derived Estimation 
Function. 

The resulting tested and verified estimation function (speci- 
fied as in Algorithm 3) would then become a tool for oper- 
ational use within a fielded data-communications scheduling 
system. The routine use of this tool would involve the follow- 
ing straightforward steps: 

Process 1 (Operational Use of Estimation-Function): 

1. Prepare a scheduling scenario 7 . 

2. Supply the characterization A ( 7 ) as input to the estima- 
tion function. 

3. Capture the estimation-function output e — the estimate 
of the optimal choice of the schedule-generation algo- 
rithm’s internal parameters for scheduling scenario 7 . 

4. Use e in configuring the schedule-generation algorithm 
for an execution ran to produce an optimal schedule for 
7 - 

7.4. The S" Problem: Discussion 

The data-regression technology called for in Algorithm 3 
is associated with extensive research and application litera- 
ture [2, 4, 6 , 9, 13, 15, 20, 22, 23, 26, 29]. For the overall al- 
gorithm optimization approach specified in Section 7 for the 
S #tt problem, it may be unjustifiable to assume the ready ap- 
plicability of off-the-shelf applications. Effective use of the 
relevant techniques and available applications may require 
trial-and-error efforts and/or the guidance of experts. 

It is explicitly assumed herein that, for the schedule- 
generation algorithm disclosed herein (see Section 5), 

• optimizing the internal parameters of the schedule- 
generation algorithm (see Section 6 ) is feassible 

• the relationship between the independent variables (the 
problem-scenario characterization) and the dependent 
variables (the solution found with fixed computing re- 
sources) is smooth enough to support approximation 
by means of some available data-regression technique 
analogous to a standard curve-fitting technique, e.g. 
the artificial neural network (ANN) techniques or some 
other “hypersurface-fitting” technique. 

• the optimization would be effective in the follow- 
ing sense: a system that implemented the schedule- 
generation algorithm would require less computing 
resources and have more rapid response in produc- 
ing high quality schedules, if it took advantage of the 
optimization of the choice of the values of the inter- 
nal parameters, than if otherwise. 


This set of assumptions has been tested by the author only 
preliminarily (relative to the prototype implementation of the 
unpublished predecessor of the algorithms in the present dis- 
closure) and may, with experience, prove to be unjustified 
with respect to the problem. For example, it may be 
found that, while the first two assumptions are confirmed to 
be valid, the third one is not: the relationship identified in 
the second assumption may be found to be essentially flat. It 
would seem more likely, however, that the relationship identi- 
fied in the second assumption lacks sufficient smoothness to 
support any reasonable optimization process using the sug- 
gested hypersurface-fitting technologies. A determination on 
this question would require involvement of experts in any 
such technology chosen for use. 

The effort needed to obtain a usable function for esti- 
mating the optimal values of the internal parameters (as de- 
scribed in the present section) would be nontrivial, but it 
would be a one-time effort with a potentially worthwhile in- 
crease in operational efficiency of the scheduling system as a 
whole. In carrying out the effort, it might be learned that no 
significant variation in solution quality resulted from differ- 
ent choices for the internal parameters. In that event, the de- 
termination could be made that the effort had insufficient re- 
turn and could be discontinued. 

8. Implementation 

8.1. Prototype Implementation of Predecessor 
Algorithm 

The author implemented the unpublished predecessor of the 
foregoing algorithms (see Sections 5 and 6 ) for a proto- 
type automated interference-mitigation scheduler and tested 
it with input data for selected scheduling scenarios for three 
actual NASA missions. For these limited cases, the proto- 
type (some 54,000 lines of C++ code) performed with effi- 
ciency at a level adequate for practical use — even when exe- 
cuted on the 1995-vintage Unix workstation available at the 
time. A limited comparison of results with output from the 
Network Planning and Analysis System (NPAS) [30] devel- 
oped at NASA Goddard satisfied the author as to the validity 
and practicality of the approach. 

In implementing the prototype, the author noted the util- 
ity of a mathematically precise specification of the algo- 
rithms. Such a specification clearly supports implementabil- 
ity. It seems reasonable to believe that an implementation at- 
tempted without such a specification but with only a typi- 
cal set of system requirements (a) would entail considerable 
risks of software rework as high level requirements became 
better understood and fleshed out in detail and (b) would re- 
quire a multiple of the schedule time and funding that would 
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be sufficient with a specification as precise and complete as 
the one provided in this disclosure. 

8.2. Implementating the Disclosed Methods 
and Algorithms 

The present version of the algorithm improves — but main- 
tains the essence of the approach of — its predecessor. In par- 
ticular, readability, implementability, and solution- space cov- 
erage are all improved. The present version should also be 
more adaptable to accommodate inevitable changes in the 
communications infrastructure, e.g., changes required to im- 
plement possible new capabilities for supporting future ex- 
ploration of the Moon and Mars. 

The implementation of the predecessor algorithm sug- 
gests no significant question as to the implementability of 
the method and algorithm disclosed herein (see Section 5 
(page 32)), given that the software-system design process is 
carried out by individuals with an adequate background in 
NASA’s Space and Ground Networks, mathematics, and ap- 
propriate data-regression technique (if the implementation of 
the SM algorithm (Algorithm 6.3 (page 35)) were planned). 

Any programming language that is in use in present 
software implementation projects in NASA’s data- 
communications network infrastructure, such as Java 
and C++, possesses characteristics that would assure suc- 
cess in implementing the disclosed algorithms. However, 
preference should be given to a language that is also sup- 
ported on an available supercomputer or grid computing sys- 
tem for the purpose of running the scheduling system’s 
internal-parameter optimization method described in Sec- 
tion 6 and especially the further algorithm for deriving an 
estimator function for the optimal values of the internal pa- 
rameters as described in Section 7. These algorithms (as 
distinguished from the schedule-generation algorithm it- 
self) are very compute-intensive and should be carried out on 
the most powerful available computing system, not on the or- 
dinary computers that would be used for development or 
operations. 

An operational implementation of the herein disclosed 
schedule-generation algorithm (Algorithm 1 (page 32)) 
might, in terms of size, be comparable to the prototype im- 
plementation of the predecessor algorithm. However, under 
current NASA system-development guidelines, opera- 
tional systems must be implemented with more- stringent 
development standards than were used for the earlier pro- 
totype implementation, and, further, must accommodate 
interfaces with existing operational systems. Conse- 
quently, the necessary size of an operational implementation 
of a new scheduling system based on the present disclo- 
sure is presently undetermined but is likely to be signifi- 
cantly greater than the size of the prototype. 


9. Conclusion 

The present disclosure describes an evolutionary (i.e., proba- 
bilistic) search strategy as the primary approach for attaining 
an optimal solution of the scheduling problem in the civilian 
or military space data-communications network. In terms of 
computer processing time for a problem domain of this kind 
(whose solution space is so large that no direct algorithmic 
prescription or brute-force method will suffice (see solution- 
space analysis in Subsection 2.2)), a probabilistic search ap- 
plication of the kind specified herein progresses, after an ini- 
tial rapid improvement in quality, monotonically in an iter- 
ative fashion towards (but without any expectation of actu- 
ally arriving at) some evident (but nevertheless unspecifi- 
able) limiting result that could not be improved upon through 
any amount of processing, relative to some prescribed mea- 
sure of “goodness” of solutions. 

At any point during processing, the amount of additional 
processing time that would be necessary to achieve an ad- 
ditional improvement over already-found solutions becomes 
greater and greater as the search proceeds. Even if no pre- 
scriptive method exists by which to find an optimum in any 
absolute sense, a probabilistic search strategy can approach 
arbitrarily close to the limiting result, given unlimited pro- 
cessing resources and time. But, as was observed in Subsec- 
tion 2.4.5, it is not known how to determine how close to 
the optimum is the best solution attained at any intermedi- 
ate point in the processing. The existence of a limiting re- 
sult (an optimum) seems intuitive, but in practice and in the- 
ory, the limiting result cannot assuredly be attained nor can it 
actually be specified — otherwise, logically, an optimum so- 
lution itself would be at hand. 

Nevertheless, it is well known that probabilistic search 
techniques and methods of the kind described herein can 
be used to reach optimal solutions for scheduling problems, 
which leaves an opening for the herein disclosed attack on 
the space data-communications scheduling problem. The rig- 
orous specification of a system based on these probabilistic 
search techniques and methods is presented fully herein for 
the NASA space data-communications scheduling problem, 
with no known previous equivalent. No other true optimiz- 
ing scheduler for this problem domain is known to have been 
specified. 

A number of constraints must be considered in design- 
ing any system that solves the space data-communications 
scheduling problem. The methods and algorithms disclosed 
herein incorporate, among others, the RF-interference miti- 
gation constraint, with the objective of assuring that the sys- 
tem generates high quality schedules that accomplish over- 
all goals of the space data-communications infrastructure. 
How and to what degree interference predictions should fi- 
nally constrain schedules represents an issue in the design of 
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such a system. While the algorithm as disclosed herein does 
satisfy RF-interference mitigation constraints, it does not ex- 
plicitly provide for fine-grained control of this factor; how- 
ever, a modification to do so could be incorporated without 
difficulty. Fine-grain control of this constraint could, for ex- 
ample, include a further parameter in the definition of mis- 
sion event (see Definition 47 (page 19)) to indicate whether 
or not to apply the constraint for a prescribed instance of a 
prototype event relative to that mission-event instance. 

While the primary context of the present disclosure relates 
to NASA, the method and algorithm have broader applicabil- 
ity, and, despite domain differences, should readily be adapt- 
able for the military context. 

Two abstractions related to the overall problem of devis- 
ing the most cost-effective possible system for generating op- 
timal schedules were developed in Section 6 (page 34) (the S s 
problem) and Section 7 (page 36) (the S^ problem). In pre- 
senting the former abstraction, Section 6 described a method 
and algorithm that increase the efficiency of the search for the 
optimal schedule given a scheduling scenario 7 , by applying 
an iterative process for determining the optimal choice of the 
values of the schedule-generation algorithm’s internal param- 
eters. For the given scheduling scenario 7 , any other choice of 
the values of the schedule-generation algorithm’s internal pa- 
rameters would mean either decreasing the expected quality 
of the generated schedule or increasing the expected search 
time for a schedule of a given quality (relative to some pre- 
scribed measure of “goodness”). In presenting the latter ab- 
straction (in a somewhat speculative vein unsupported by ex- 
perimental results), Section 7 builds upon the method and al- 
gorithm in Section 6 and describes a further method and ap- 
proach by which to obtain an estimator function that, given 
a scheduling scenario (or its characterization via a charac- 
terization function), would return an estimate of the optimal 
choice of the values of the schedule-generation algorithm’s 
internal parameters, thus assuring (in the full embodiment 
and application of the technology disclosed herein) the most 
cost-effective possible system for operational use in gener- 
ating optimal, constraint-satisfying schedules for the civilian 
or military space data-communications infrastructure. 

Before leaving the subject of the NASA space data- 
communications scheduling system, Appendix A explores 
an assumed model of the performance of the probabilis- 
tic search techniques described in the main body of the 
present disclosure. Analysis of the model imparts un- 
derstanding and insight into the issue of how the dis- 
closed evolutionary-search algorithm’s internal parameters 
might be set to maximize performance of the system in op- 
erational use. 

Finally, Appendix B describes a class of problem domains 
(the Type-G problem domains), which encompasses a very 
broad range of optimization problems including the space 


data-communications scheduling problem, among many oth- 
ers. A rigorous specification of algorithms and methods for 
reaching optimal solutions for problems of Type G is dis- 
closed. The disclosed specification affords to developers an 
efficient implementation path for developing systems to solve 
such problems. 


10. Appendix A. Modeling Algorithm 
Performance 

10.1. Best-Solution Fitness Modeled as a 

Function of Algorithm-Iteration Count 

To support an effort to gain insight into the nature of the 
optimization attainable by the schedule-generation algorithm 
(Algorithm 1 (page 32)) and the S* algorithm (Algorithm 2 
(page 35)), we will assume and analyze a model for the per- 
formance of the schedule-generation algorithm. We will as- 
sume that for a given scheduling scenario 7 and a given 
choice e of the values of the internal parameters of the 
schedule-generation algorithm, the solution (schedule) fit- 
ness plotted against the iteration count during a run of the 
algorithm would be representable by a function having the 
form: 

= 7 7*77 b 9 ( 1 ) 

(p— u) +w 

where the independent variable p G N + represents the it- 
eration count during a mn of the algorithm, and the depen- 
dent variable f(p) represents the fitness of the best sched- 
ule in the schedule population at the end of that iteration. 
The values of the parameters v, u,w,q,z £ R determine 
the precise curve that approximates the performance of the 
schedule-generation algorithm (for the given scheduling sce- 
nario 7 and given choice e of the values of the internal pa- 
rameters). 

Figure 4 (page 41) illustrates an instance of the function 
/ (with particular values for the parameters v, u, w, q, and z) 
along with the derivative of / with respect to p: 

d /(p) = -vz (p - u ) z ~ 1 ^ 

dp ((p — U Y + w ) 2 

Note that the value of /( 0) is finite (assuming (0 — u) z + 
w ^ 0), corresponding to the fact that the population of ran- 
domly formed solutions at the initialization of the run of the 
schedule-generation algorithm (Step lc, page 32) will have a 
range of fitness scores, all of which will be finite values. The 
intersection of the function / with the vertical axis represents 
the best score in the range of scores of the members of the ini- 
tial population. Of course, a negative iteration count is mean- 
ingless and so the model / for the performance of the algo- 



40 



10.2 Assumed-Model Versus Actual Performance 


1 0 APPENDIX A. MODELING ALGORITHM PERFORMANCE 


rithm as a function of algorithm-iteration count has no mean- 
ing to the left of the vertical axis. 

An everywhere differentiable monotonic function (such as 
/) has a monotonic derivative, and in the case of the present 
model, the derivative is always negative, corresponding to 
the fact that the assumed fitness model is a function whose 
slope is always negative — corresponding, in other words, to 
the fact that the fitness, in general, improves with increas- 
ing iterations of the schedule-generation algorithm. Note that 
the rate of improvement decreases with increasing iterations 
of the schedule-generation algorithm. 



Figure 4. Best-Solution Fitness modeled as a 
function of the schedule-generation algorithm 
iteration count (upper curve) (Equation 1), and 
its derivative (lower curve) (Equation 2). Points 
on the graph to the left of the vertical axis are 
to be ignored, since they are meaningless in 
relation to the actual performance of the al- 
gorithm. The model for fitness is assumed to 
be a continuous function, whereas the actual 
performance is a set of discrete points, one 
for each integer representing the schedule- 
generation algorithm iteration count. 


10.2. Assumed-Model Versus Actual 
Performance 

Whether such a function (Equation 1) could be a fair rep- 
resentation of the actual performance of the schedule- 
generation algorithm makes a reasonable question that is dif- 
ficult to answer in the affirmative, but it can be argued that at 
least some such function would be a worst-case representa- 
tion. 

The actual performance of the schedule-generation algo- 
rithm, as previously indicated, is, for a given mn of the al- 
gorithm, a discrete (and monotonic) function of the iteration 
count during the run. That is, the quality of the best schedule 
in the population at the end of an iteration will be the ordinate 
of a discrete point whose abscissa is the iteration count, and, 
plotted against iteration count, all such points resulting from 
the run will be separate dots on the graph, as illustrated in 
Figure 5. Since the performance of the schedule-generation 
algorithm has a monotonic relation to the iteration count, if g 
is the set of points representing the performance of any given 
run of the algorithm, then there exists a model — i.e., an in- 
stance / W o re t of Equation 1 (with some choice of the values 
of the parameters v,u,w,q, and z ) — such that 

1. 3a; 6 dom(p) 9 g( x) = U orst {x) y and 

2. Vx 6 dom(p) 9 g{x) < / woret (z) 

and we can refer to this instance of Equation 1 (see Figure 5) 
as the worst-case model of the actual performance. In the re- 
maining subsections of this appendix, the worst-case model 
can be considered to be the subject of the discussion. 

Two further observations are offered regarding Figure 5. 
First, the discrete points in the lower graph are merely repre- 
sentative and are not actual data from a run of the algorithm. 
However, the lower graph is notionally consistent with ac- 
tual execution results of genetic-algorithm applications gen- 
erally (for example, see [27]). Second, the Equation 1 model, 
even if it is the worst-case model as depicted in the upper 
graph in Figure 5, suggests a means of judging a trade-off 
between the quality of the results from running the algorithm 
and the power of the computing resources (or the processing 
time) needed. The model represented by the upper graph has 
a kind of “knee” where the slope of the curve changes more 
rapidly than for points either to the left or to the right. To 
the right of the knee, there is a diminishing-retums situation. 
The farther to the right, the less improvement in schedule 
quality expected from a run, but the more computing power 
(or processing time) required to attain that improvement. To 
the left of the knee, there is a larger gain in improvement 
for a given increment in additional computing power (or pro- 
cessing time). In view of the diminishing returns of applying 
more processing resources at the far right end of the graph, 
one insight gleaned from considering the model (even the 
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Figure 5. Best-Solution Fitness versus it- 
eration count. The discrete points in the 
lower graph represent a hypothetical run of 
the schedule-generation algorithm. The up- 
per curve is a graph of Equation 1, the as- 
sumed model of fitness as a function of it- 
eration count during a run of the algorithm, 
with choices for the values of the parameters 
v, u, w, q, and z so as to obtain a best-fitting 
curve of the form of Equation 1 having the dis- 
crete points as a lower bound. 


worst-case model) is that reaching a judgement concerning 
a trade-off between computing power (or processing time) 
and the quality of the results from running the algorithm can 
be expected to be facilitated by actual experience running the 
algorithm. Further, such experience would augment under- 
standing as to how quickly the “knee” will be reached, as 
well as how long it may take to reach the point of negligi- 
ble expectation of further improvement. 6 

10.3. Fitness as a Function of a Single 
Parameter 

We now consider the behavior of the model when a full run 
of the algorithm is repeated with a change in the value of 
one of its internal parameters. In the repeated run, no other 
change is imposed. For the present discussion, we let the pa- 
rameter n represent the change in the value of internal pa- 
rameter Qfj (see definition of cc in step le of the specification 
of Algorithm 1 (page 32)). Thus, in each iteration of the al- 
gorithm during the repeated run, at step j + 4 (noting that 
step 4 (page 32) is the first step performed in each iteration) 
the number of candidate schedules to be generated for inclu- 
sion in the population will be changed by the value of n. 

For the initial mn (which is assumed to have reached a 
point in the processing where a large additional amount of 
processing would not entail a significant expectation of im- 
provement in the fitness of the best schedule, thus reaching 
an optimum), let p denote the total number of iterations, so 
far, of the steps of the schedule-generation algorithm, and let 
m s denote the number of schedules (i.e., solutions) gener- 
ated and considered during the run. Then 


m s =n 0 + pn 0 


( 3 ) 


where no is as defined in step lb (page 32). 

When the run is repeated, the total run time will be the 
same (governed by the run-time limit v defined in step la 
(page 32)). The generation and evaluation of the schedules 
created during a given iteration will consume a greater or 
lesser total amount of computation time, and will decrease 
or increase the number of iterations of the algorithm during 
the run, but the total number of schedules that can be gener- 
ated and evaluated during the repeated run will be the same, 
equal to m s , as for the initial run. Thus, with m s constant be- 


6 Consideration of these expectations would tend to be reminiscent of the 
law of diminishing returns — and interesting relationship between pro- 
duction and effort in the sense studied in economic theory. It may also 
remind the reader of another diminishing-returns situation found in the 
Special Theory of Relativity in which any constant application of en- 
ergy applied by a propulsion system to increase the speed of a space- 
craft eventually produces a vanishingly small increase in speed as rela- 
tivistic effects cause the spacecraft mass to increase without bound. 
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Figure 6. Best-Solution Fitness as a function 
of the parameter n (representing the change 
in the fixed number of new members gener- 
ated at each step) for the assumed model (see 
Equation 6). 



Figure 7. Derivative of best-solution fitness as 
a function of n (representing the change in the 
fixed number of new members generated at 
each step) for the assumed model (see Equa- 
tion 7). 


tween the runs, for the repeated run, we have 

m s = n 0 + p(n 0 + n) (4) 


and so the iteration count can be considered to be a function 
of n € N, the independent variable representing the change 
in the number of new schedules that will be added in some 
prescribed step of the schedule-generation algorithm: 


p(n) 


m s - n 0 
n 0 + n 


( 5 ) 


Equation 1 can now be rewritten to express the fitness 
function in terms of n: 


/(«) 


( rag n o 

n 0 +n a J 


+ Q 


+ w 


( 6 ) 


illustrated in Figure 6. Notice that the fitness worsens for ev- 
ery positive value of n: the slope of the graph is everywhere 
positive. The derivative of fin), given by Equation 7 and il- 
lustrated in Figure 7, is always positive, approaching the hor- 


izontal axis asymptotically. 
d f{n) _ vz (m s - ra 0 ) ( n 0 +n ~ M ) 

d " ((^-«)'+») 5 {n ° +n)2 

From these observations it is seen that a larger value of n 
worsens the fitness by a greater amount than does a smaller 
one, but the effect diminishes with ever larger values of n. 

Thus, when the algorithm’s performance is directly related 
to the number of iterations of the steps of the algorithm, as 
in the assumed model (Equation 1), the following questions 
arise: 

First, does the model of fitness as a function of n (the 
change in the number of candidate schedules generated in 
some prescribed step in each algorithm iteration for inclu- 
sion in the population in the repeated run) (see Equation 6 
(page 43)) imply that arbitrarily increasing the value of an 
internal parameter necessarily brings a decrease in the qual- 
ity of the best solution (schedule) — in comparison to the best 
schedule that can be produced in the number of iterations per- 
formed in the initial run? 
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Second, does the model imply that decreasing the value of 
an internal parameter in the repeated run necessarily brings 
an increase in the quality of the best solution (schedule) — in 
comparison to the best schedule that can be produced in the 
number of iterations performed in the initial run? 

In each run of the algorithm (when used as specified 
in Algorithm 1), values of the internal parameters are held 
constant (i.e., the number of candidate solutions (schedules) 
added in each of the algorithm’s steps 4 through 15 (page 33) 
remains the same until the end of the run). At the end of the 
run (the duration of which will equal the run-time limit v), 
the system will output the best schedule in the population. 
In a repeated run with the increase/decrease of n in the num- 
ber of candidate schedules generated in each iteration, even if 
all other parameters are held the same, at any given iteration 
number, say the Mi, the algorithm will necessarily have con- 
sidered either more schedules or fewer schedules (depending 
on whether n is positive or negative), and from the first iter- 
ation onward, the population of schedules will increasingly 
diverge from the population in the initial ran. Therefore, the 
model assumed in Equation 1 has limited use in answering 
the stated questions, but nevertheless affords a useful insight 
into the setting of the algorithm’s internal parameters, as dis- 
cussed in the next section. 

10.4. Fitness as a Function of Elapsed Run 
Time 

It will now be insightful to analyze the behavior of the fit- 
ness model (Equation 1) as a function of the elapsed run time 
of the algorithm, when holding fixed the value of n (i.e., the 
variable representing the change in the value of a single inter- 
nal parameter as described in the preceding section). In this 
analysis, we assume we are given the following: 

1. v, the duration of the algorithm execution run 

2. no, the number of schedules added to the population 
during each iteration of the steps of the algorithm 

3. n, the change (relative to a previous run) in the value of 
a single internal parameter as described in the preced- 
ing section 

4. m s , the total number of schedules that can be added 
and evaluated during a run of duration v seconds as de- 
scribed in the preceding section 

With the above given information, we seek to reformulate 
Equation 1 to calculate the fitness of the best member of the 
evolving population of schedules as a function of time. 

Since m s schedules can be created and evaluated by the 
algorithm during a run of v seconds duration with the as- 
sumed given computing resources, the time required to cre- 


ate and evaluate each schedule (as an overall average) is 

v 


m s 

When the iteration count is p during a second run of the 
algorithm, the cumulative number of schedules added will be 

n CU m = n 0 + (n 0 + n)p 


It is now possible to calculate how much time has elapsed 
when the run reaches iteration p: 


,^ = (n. + (H0 + ")l p)^r 


We can now express the iteration count p as a function of 


t: 


p(t) = 


m s t — tiqv 


(n 0 + n)v 

Thus, Equation 1 can be rewritten to relate fitness to 
elapsed run time t: 

v 


m 


( m f t—nov \ I 

^ (no +n)u U ) 


+ Q 


( 8 ) 


illustrated in Figure 8. In the upper curve, the value of n is 
a positive number, and, in the lower curve, n is a negative 
number of the same magnitude. The conclusion from these 
two curves is that, given any two runs of the algorithm where 
the first has a larger, and the second has a smaller, number n 
of schedules added in each iteration, and given any particu- 
lar elapsed time t during each ran, the run that has the smaller 
value of n will have a better value of the fitness of the best 
member of the population at time t. The two curves illus- 
trate the fact that the effect is greatest at the beginning of the 
run and necessarily vanishes at the end when the elapsed time 
equals v. 

However, these relationships are subject to a caveat. In the 
second run of the algorithm contemplated above, the popu- 
lation starting at the second iteration of the steps of the al- 
gorithm begins to diverge from that of the first run, since the 
number of schedules added in each iteration in the second run 
will be either greater than or less than the number added in 
each iteration in the first run. The model described by Equa- 
tion 1, while arguably representative of the performance of 
the system during any given ran, has no relevance to the dif- 
ferences between two different runs. If Equation 8 or Fig- 
ure 8 is at all suggestive of some guidance in setting the val- 
ues of the internal parameters, it would be that smaller rather 
than “large” values would improve performance. 


10.5. Key Insight Afforded by the Assumed 
Model 

Clearly, the model assumed in Equation 1 does imply that in- 
creasing or decreasing the number of iterations in a ran in a 
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Figure 8. Fitness modeled as a function of the 
elapsed run time, holding fixed the value n for 
the change in the value of a single internal pa- 
rameter. Two runs are illustrated. The upper 
curve has n set to a positive number, while the 
lower curve has n set to a negative number of 
the same magnitude. 


manner that does not result in a difference in the number of 
candidates generated in any step of the algorithm (by, for ex- 
ample, increasing or decreasing the value of u) will, in gen- 
eral, correspondingly affect the quality of the solution pro- 
duced by the algorithm. 

Significantly, the model of fitness as a function of the pa- 
rameter n (see Equation 6 (page 43) and Figure 6 (page 43)) 
implies that the number of new schedules that will be added 
in each step of the algorithm is very important: negative val- 
ues of n result in generating fewer candidate schedules in 
each iteration, and therefore result in a greater number of it- 
erations during the run. This, together with the analysis in 


Section 10.4, leads to the hypothesis that experimentation 
(or, better, the application of the S 8 algorithm (Algorithm 2 
(page 35))) would show that the optimal choice of the val- 
ues of the internal parameters for a given scheduling sce- 
nario would entail smaller values rather than larger. 

This is perhaps the most useful insight to be drawn 
from considering the above model of the performance 
of the schedule-generation algorithm — namely, that de- 
spite the fact that the specification of the algorithm is 
silent on how to choose the values of the internal param- 
eters, large values would be contraindicated. This insight 
still does not give quantitative guidance on what con- 
stitutes “large” values, however, and therefore does not 
really substitute for the quantitative guidance that ulti- 
mately would be available when a solution to the S 88 prob- 
lem is implemented as described in Section 7 (page 36). 
But the stated insight suggests that even routine experi- 
ence running an implementation of the schedule-generation 
algorithm would eventually lead to a level of practical under- 
standing of at least how not to set the values of the internal 
parameters. 

11. Appendix B. The Generalized 
Algorithms and Methods 

11.1. The General Problem 

11.1.1. Introduction. 

In this appendix, we present a generalization of the methods 
and algorithms (and of the problem domain itself) that were 
described in Section 5 (page 32), Section 6 (page 34), and 
Section 7 (page 36). Reaching toward such a generalization 
is motivated by the recognition (a) that there are many dif- 
ferent problem domains where an evolutionary search strat- 
egy can be used profitably, and (b) that application develop- 
ers may benefit from having such a generalization in translat- 
ing to another domain the methods and algorithms that were 
described herein for the NASA space-data-communications 
scheduling problem. 

The generalization presented in this appendix is intended 
to facilitate development of applications for any problem do- 
main matching the essential characteristics of the Type-G 
problem domain defined below. While the Type-G problem 
domain is not all-encompassing, it is general enough to be 
broadly useful and has certain characteristics that facilitate 
implementation as well as efficient computation. (For ex- 
ample, integer values suffice for the vast majority of all of 
the calculations that are required for execution of the algo- 
rithms.) 
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This appendix also delineates steps for implementing the 
generalized methods and algorithms. 

Material to be presented below starts with a description 
of Type-G problems and the approaches for reaching opti- 
mal solutions to such problems, and progresses then to de- 
scriptions of Type-G problem abstractions that, along with 
methods to solve them, are designed to support the optimiza- 
tion of those approaches themselves, for use in fielded sys- 
tems that solve Type-G problems. The abstractions, based on 
the idea of Type-G meta problems, are referred to as the G* 
and GM problems. 

11.1.2. Basic Definitions. 

In the case of the earlier treatment of the NASA space- 
data communications-scheduling problem, a problem sce- 
nario was a set of data structures that, in part, expressed user 
requirements for data-communications events by which sci- 
ence data (among other kinds of data) could be returned to 
earth via antennas in the NASA data-communications sup- 
port infrastructure, or by which commands or other types 
of data could be received from earth by the user spacecraft, 
again via antennas in the NASA data-communications sup- 
port infrastructure. A problem scenario also contained addi- 
tional data structures comprising infrastructure constraints, 
characteristics of support antennas, etc. 

Similarly, in the case of the generalized problem domains 
that we are discussing in the present section, a problem sce- 
nario is considered to be a finite data structure that expresses 
requirements and constraints that a problem solution must 
satisfy. 

Definition 124: 7 is a problem scenario of Type G => 3fc € 
N + 9 7 is a sequence of exactly k finite data structures that 
expresses requirements/constraints that are internally consis- 
tent and that every allowable solution for 7 must satisfy. 

Definition 125: 

T = { 7 : 7 is a problem scenario of Type G}. 

T is the set of all possible problem scenarios of Type G. 

Definition 126: T h;™ : n+ -> p(r) 9 

V(fc, 7) 6 N+ x r ,7 6 rdta(fc) len( 7 ) = k. 

r dim (/c) is the set of all problem scenarios of length k (i.e., 
of dimension k). 

Relative to the optimization issues addressed in this dis- 
closure, we will refer to problem domains of Type G defined 
as follows. 

Definition 127: A = j<5: 3k p € N + 9 5 C. r d j m (fc p ) j. 

Definition 128: 


5 is said to be a problem domain of Type G if and only if 
6 e A. 

A problem domain of Type G is a set of Type-G problem sce- 
narios all having the same dimension. 

Note that the term “Type-G problem”, as distinct from the 
term “Type-G problem domain”, will have a more specific 
definition (see Definition 136 (page 48)). 

Definition 129: A^ : A -> N + 9 V(S, k p ) 6 A x N+, 
A d im (3) = kp ' t = 7 > [V 7 G S, len( 7 ) = k p J 

A dim ((5) is the dimension of 6, i.e., A dilJ 1 (5) is a positive in- 
teger representing the length of every problem scenario in d. 

We now identify the set of all permissible solutions for 
Type-G problem domains. 

Definition 130 (Set of All Permissible Solutions): 

0 = {(9: e A , 37669 

6 is a permissible solution for problem scenario 7 j. 

0 is the set of all permissible solutions for all problem sce- 
narios 7 6 8 6 A, with no omissions or exceptions. The 
problem-domain dependent notion of “permissible” is left 
undefined. 

Definition 131 (Set of All Permissible Solutions for a Given 
Problem Scenario): ©scenario : Axf-4 p(0) 9 
V(<s, 7 ) G A X T 9 7 6 8,9 E ©scenario^, 7 ) «=► 

9 is a permissible solution for problem scenario 7 . 

11.1.3. Associating Generalized Problem Domains with 
Real Problem Domains. 

It will be taken for granted herein that the context for discus- 
sion relates to a certain class of real-world problems for each 
of which the following hold: 

• it can be stated in some proper manner and given an ap- 
propriate working association with some member of A, 

• it has a definable solution that can be expressed as a fi- 
nite data structure, and 

• its implementation following the generalized methods 
and algorithms disclosed herein would flow from the 
actual problem statement and its associated member of 
A. 

The way in which a problem domain in this class might 
be given an association with a member of A, and the specifi- 
cation of the implementation of the actual problem statement 
in the context of the generalized methods and algorithms, are 
each beyond the scope of this disclosure. 

The foregoing definitions lead to the following observa- 
tions concerning a problem domain of Type G: 
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1. There exists a function that assigns to each allowable 
solution for any given problem scenario a quantitative 
“goodness” or “fitness” score. 

2. Every problem scenario has an optimal solution with 
reference to a given fitness function. 

Type-G problem domains are numerous and varied, and 
include not only the schedule-optimization problem ad- 
dressed earlier by means of evolutionary search (genetic 
algorithms) (Section 5 (page 32)), but also the meta prob- 
lem designated as the S* problem that likewise was addressed 
by means of evolutionary search (genetic algorithms) (Sec- 
tion 6 (page 34)). 

11.1.4. A Note on Applicability. 

While in theory the disclosed generalized methods and algo- 
rithms could be used to reach a solution to many problems 
for which standard numerical or closed-form methods exist, 
such usage would be inefficient and would produce less ac- 
curate solutions. Nothing in this disclosure is to be construed 
so as to obviate common sense in the use of the methods de- 
scribed herein. Only appropriate applications are to be con- 
templated. 

There are numerous appropriate applications of the meth- 
ods and algorithms specified in this appendix for reach- 
ing optimal solutions of problem scenarios of Type G. The 
design-optimization applications in the realm of space mis- 
sions mentioned in Section 1.6 (page 6 ) are representative of 
a wide variety of design-optimization problems, from archi- 
tecture to automobiles to industrial plants to rail systems to 
product packaging, to mention only a few that — 

• can be found in the literature concerning applications of 
evolutionary search, 

• can be classified as problems of Type G, and 

• therefore can be solved by a system following the meth- 
ods and algorithms specified herein. 

Scheduling and planning generally can be cast as prob- 
lem domains of Type G. But the range of Type-G problems 
is greater yet, and is not likely soon to be fully traversed. 

11.1.5. The Essential Evolutionary Search Functions. 

Genetic algorithms, and evolutionary programming, are ap- 
plicable to a broad range of problems (see discussion in Sec- 
tion 2.3 (page 10) and Section 2.4 (page 11)), and form the 
central technical approach for solving Type-G problems as 
presented herein. The essential mechanisms of evolutionary 
search (beyond the basic notion of evolving a population of 
candidate solutions through an iterative process) are 

• fitness 


• random selection 

• genetic mutation 

• genetic crossover 

These mechanisms will be embodied in functions defined 
below. 

11.1.5.1. Fitness Functions. A crucial part of an evolu- 
tionary search algorithm as described herein is the fitness 
function that will be used to evaluate candidate solutions in 
the solution space. A valid fitness function for a given prob- 
lem scenario 7 maps each member of the set of all per- 
missible solutions for 7 to a real number greater than or 
equal to 1 , where unity is the fitness of a perfect solution. 
While other choices for the definition of “perfect” fitness are 
worth considering, the chosen value, 1 , affords certain de- 
sirable numerical advantages for constructing an actual fit- 
ness function. For example, the fitness function defined in 
Definition 103 (page 28) for the space-data communications 
scheduling problem constituted a number of independent 
sub-functions, each defined with fitness in the semi-closed 
interval [ 1 , 00 ), where the final fitness was computed as the 
product of the values returned by the constituent functions, 
thus ensuring that the final fitness value always remained in 
[ 1 , 00 ) and, further, that the final fitness value strongly re- 
flected the degrading effect of any one of the constituent val- 
ues that exceeded 1 . 

More exactly, 

Definition 132 (Set of All Fitness Functions): 

^fitness : A X r ^ p([l,Oo) ) 9 

v(< 5,7) e a x r,/ e F fltn ess(<5,7) <=> 

1. dom(/) = ©scenario^* 7) 

2. VO, O' G ©scenario (6, 7), 

f(0) < f(0') => 0 is more fit than O' . 

-Ffitness(<5,7) is the set of all possible fitness functions for 
problem scenario 7 in the target problem domain 5. (See Def- 
inition 1 1 (page 17) for the meaning of the notation of the 
form X Y , where each of X and Y is a set. In the present def- 
inition, [ 1 , 00) 0 designates the set of all functions that map 
0 to the semi-closed interval [ 1 , 00 ) on the real-number line.) 

11.1.5.2. Random Selection. The search strategy also 
employs, for given problem scenario 7 for given target prob- 
lem domain 5, a means to create a set of new candidate mem- 
bers of the working population by either (a) randomly 
generating permissible solutions for 7 or (b) randomly se- 
lecting members of ©scenario (£, l)- 

Definition 133 (Selection of a Random Set of Solutions): 

^randomselection : A X T ^ P^(p(©)) ^ 9 
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\'((). 7 ) £ A X T, / £ ^random.sdection (5, 7 ) 4^ 

1. COdomain(/) C p(0scenario(5,7)), 

2. Vn € N+,/(n) = RND(n, ©scenario (A, 7))- 

Note that this function is a “pseudo function” (see remark be- 
low Definition 15 (page 17)). 

11.1.5.3. Mutation Functions. Evolutionary search algo- 
rithms also involve functions that generate new candidate 
members of the working population of solutions using mu- 
tation and crossover concepts (see the discussion of genetic 
algorithms in Section 2.4 (page 11)). To generate a mutation 
of a member 6 of the working population during a search, a 
new data structure is created representing the new member 
of the population, i.e., the mutated version of the given mem- 
ber 6. The new data structure (a finite data structure by defi- 
nition) will be the same as that of the given member 6, except 
for some deliberate (yet random), problem-scenario-specific 
alterations made by the mutation function. Once created, the 
new member is incorporated into the working population on 
an equal footing with all other members until the member- 
evaluation phase of the search algorithm is reached during 
an iteration through the steps of the algorithm. If by chance 
the mutation produces a child that is identical with its parent, 
then it will be ignored. It may be noted that the mechanism 
for making mutations legitimately may not select purely ran- 
dom parts of the data structure representing a member of the 
population, as such a mutation mechanism would likely pro- 
duce offspring containing uninterpretable/impossible data, 
rendering them impermissible as solutions of the given prob- 
lem scenario. Therefore, it may be taken for granted that the 
mutation mechanism must not lead to nonsensical or other- 
wise impermissible offspring. 

Definition 134: Fetation : A x T -x p(0 e ) 9 
^(^> 7 ) s A X r, / € (5, 7 ) 44- 

1. dom(/) = 0scenario(5, 7) 

2. codomain(/) C 0scenario(A,7) 

3. 6 € mdmember (©scenario (5, 7 )) => 

f{6) is a random mutation of 6. 

^mutation (5, 7 ) is the set of all possible mutation functions for 
problem scenario 7 in the target problem domain 6. Note that 
this function is a “pseudo function” (again see remark below 
Definition 15 (page 17)). 

11.1.5.4. Crossover Functions. The crossover mecha- 
nism is defined similarly. A crossover function accepts two 
randomly selected members of the current working popula- 
tion and produces, in some random yet problem-scenario- 
specific manner, two new members whose characteris- 
tics and fitness will be determined partly by each of their 


“parents” — the two given members. Each crossover func- 
tion operates by identifying two random crossover points. 
The crossover points define segments of the data struc- 
ture of each of the parents. Once the segments are deter- 
mined, the two “children” of the parents will be assem- 
bled from their parents’ corresponding segments in such 
a way that the children differ from each other and from 
each parent — preserving, in that way, the concept of swap- 
ping some, but not all, of the chromosomal material be- 
tween the parents as a means to produce the children. If 
by chance the children and their parents do not all dif- 
fer from each other — a result that is not allowed — then it 
will be necessary to repeat the step for randomly select- 
ing the parents and the segments to be swapped. It may 
be noted, again, that the crossover points legitimately may 
not define purely random parts of the data structure rep- 
resenting a parent, as swapping portions defined in that 
manner would often (perhaps nearly always) produce off- 
spring containing uninterpretable/impossible data, render- 
ing them impermissible. Therefore, it may be taken for 
granted that the mechanism for selecting crossover points 
must not lead to nonsensical or otherwise impermissible off- 
spring. 

Definition 135: F cn)SSOTer : A x F — x p((0 2 ) 02 ) 9 
7 ) 6 A x T, f 6 F crossover (5, 7 ) 4=X 

1. dom(/) = ©scenario (5, 7 ) 2 > 

2. codomain(/) C ©scenario (5, 7 ) 2 , 

3. {6,6') e mdmember(0 scenario (5,7) 2 ),6> ^ 6' => 
f{6,6') is a pair {6 C ,6' C ) of children generated as 
crossovers between parents 6 and 6'. 

F CT ossover(5, 7 ) is the set of all possible crossover functions 
for problem scenario 7 in the target problem domain 6. Note 
that every member of F CTOSS 0 TCr (5, 7 ) is a “pseudo function”. 

We now seek to formulate the Type-G problem, generally 
applicable to any problem domain of Type G. 

11.2. The Type-G Problem 

A Type-G problem is a member of the set G : 

Definition 136 (Set of All Type-G Problems): 

G C A xTxN+ x [0, 00 ) x (N +) 3 x (p(0)) N+ x [1, oo) e x 

0© x ( 0 2)0 2 x 0 3 

9 = (5, 7 C 5, V, T, a, f T , /test, fm, fc, 7r) S G => 

1 . v represents, in units of seconds, an adequate run time 
for the search, 

2. t represents a small value (not necessarily positive) that 
reflects the user’s judgment or policy as to how close to 
perfect a solution for the given problem scenario must 
be to be considered “good enough”, 
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3. a is a vector (i.e., a tuple (ai,a 2 , . . . )) consisting of 
values of the internal parameters of g, with len(a) = 
Adim(<5), 

4. fr G -Prandomselection (5, 7)> 

5. /test G -Ffltness(^) T)> 

6 . fm G ^mutation fit 7) > 

7* /c G ^crossover(^) 7)> 

8 . 7T S 0scenario(^, 7)- 

5 is said to be a Type-G problem if and only if g G G. 

It will be useful to identify the Type-G problems for a 
given Type-G problem scenario 7 , as follows: 

Definition 137 (Set of All Type-G Problems for a Given 
Problem Scenario): G scena rio : A x T — » p(G) 9 

v(<5,7 )eAxr\ 

Gscenario(^7) = { fit 7, •) € Cl- 

11.3. Type-G Problems: The G-Algorithm 

In moving on toward defining an algorithm for solving a 
Type-G problem, it will be helpful to define a function that 
embodies certain steps that must be performed by the algo- 
rithm relative to a given set of candidate solutions of a given 
Type-G problem: 

Definition 138 (Internal Steps of a G-Algorithm): 

Wsteps : p(0) XG9 p(0) 3 

V(n ,g = (6, 7, v, r, a, / r , /test, /m, /c? 7r)) e p{G) x G 
if 

1 * n C ©scenario O 0 * 

2. ^population = > 

j£{l,... 5 len(a)} 

3# |n| > ^population » 

4. iii = rnd(q!i, n), 

5 . n 2 = RND(ia 2 ,n 2 ) 9 ( 6 , 0 ') g n 2 =* 

-( 0 ', 0 ) en 2 , 

6. n 3 = ( U {/-(«)}) U 

Veeni J 

U {fc{0i,0 2 )}\ U/r(«3),and 
(0i 5 02)en 2 / 

7. n 4 c n 3 9 

(a) |n 4 | = ^population and 

(b) [#i G n 4 ,0 2 G II 3 \H 4 ] => /test(^l) < /test (^ 2 )* 

then Wsteps(n,5) = n 4 . 

The G-algorithm for solving a Type-G problem is an 
evolutionary-search algorithm specified as follows: 


Algorithm 4 (G-Algorithm Specification): 

Given: 

• 9 = fit It v , T, a , f T , / test , / m , /c, 7r) G G 
Perform the following steps: 

1. Letll = fr( E a j\ 

V j£{l,...,len(a)} / 

2. (a) Let II / = W^teps(r[,p). 

(b) Find tt' G II' 9 £ G II' => / te st(C) > /testK)- 

(c) Set 7T = 7r'. 

(d) Set n = ir. 

(e) If ft (tt) < 1 + t or runtime exceeds v, then exit, 
returning the value 7r; otherwise, go to step 2a. 

When the G-algorithm is executed to solve a Type-G prob- 
lem g = (5,7, v, T, a, fr, /test, fm, fc, tt) G G, the result is 
that 7r has been set equal to the optimal solution for the prob- 
lem scenario 7 G 6. This optimal solution is calculated given 
a, the vector of the values of the Type-G problem’s internal 
parameters (where a different choice of their values would 
generally result in a different solution for the problem sce- 
nario 7). 

11.3.1. Execution of a G-algorithm. 

Executing the G-algorithm (Algorithm 4) for a given Type-G 
problem 

9 = fi, 7, V, T, a, fr, first, fm, fr, 7r) G G 

consists of performing the prescribed steps given in the speci- 
fication of Algorithm 4 and capturing the final value returned. 

Definition 139 (Function to Execute the G-algorithm (Algo- 
rithm 4)): 

/g-«xecute ■ G X 0 9 

V 9 = (<5, 7, v t r, a, fr, /test, fm, fr, tt) e G, 
if 7r is the optimal solution for problem scenario 7 as re- 
turned from a run of the G-algorithm (Algorithm 4 (page 49)) 
against the Type-G problem g, 

then /g-execute(fl') = TT- 

Note the implicit dependency on the computing resources: 
the quality (that is, the fitness) of the output result 7r will, 
in general, be improved through the use of a more power- 
ful computing platform. 

11.4. The G# Problem 

Having described the general problem domain of Type G and 
an algorithm by which to find its optimal solution, we pro- 
ceed along the line of deliberation indicated in the introduc- 
tion (Subsection 11.1.1 (page 45)). That is, we proceed to de- 
scribe methods, algorithms, and processes by which 
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1. a Type-G problem may be optimized (thus assuring tbe 
maximum performance of the G-algorithm itself), and 
by which the Type-G problem of doing this can be opti- 
mized, and, again, by which the Type-G problem of do- 
ing that can be optimized, etc., indefinitely (which is 
referred to as the G* problem), and 

2. a mechanism (the G** algorithm) can be derived by 
which all of the problem scenarios in a given Type- 
G problem domain may be solved with maximum ef- 
ficiency. 

These additional optimization methods depend on the 
concept of a Type-G meta problem. 

11.4.1. Regarding Type-G Meta Problems. 

Importantly for our purposes, the G-algorithm specification 
(Algorithm 4 (page 49)) applies not only to finding an opti- 
mal solution for a given target problem domain of Type G, 
but also to optimizing the Type-G problem itself. Suppose 
that, by Definition 136 (page 48), 

9 = (<*, 7) v, t, a, f r , /test, f m , f c , t r) € G 

is a Type-G problem of finding an optimal solution for a 
given problem scenario 7 in target problem domain 8. Then 
there is a “meta” problem 8' and a “meta” problem scenario 
7 ' € 8' for finding the optimal choice of the values of the in- 
ternal parameters of g, and this problem is solved as another 
Type-G problem 

g' = {5', V, V, r', a', & fU /;, /', tt') € G 

The remaining elements of the tuple g' are to be consistent 
with Definition 136 and must satisfy certain additional con- 
ditions that will be described below. 

11.4.2. Meta-Problem Scenarios Compounded 
Indefinitely. 

Consider (as suggested above) an infinite sequence of Type- 
G problems whose first element is g, a Type-G problem of 
deriving the optimal solution of some Type-G problem sce- 
nario 7 , where each element after the first element of the se- 
quence is formed as the Type-G problem of optimizing the 
choice of the values of the internal parameters of the preced- 
ing Type-G problem in the sequence. This idea, designated as 
the G* problem, will, as in the S* problem, entail evolution- 
ary search (genetic algorithms) as the favored solution tech- 
nology. 

Given a Type-G problem g in the infinite sequence men- 
tioned above, the successor Type-G problem, g ' , represents 
the task of solving the Type-G meta problem of optimizing 


the choice of the values of its predecessor’s internal param- 
eters. The problem scenario for g' would be a data structure 
that stipulates the requirements and constraints applicable to 
the solution of the Type-G meta problem (and this data struc- 
ture would be in one-to-one correspondence with the data 
structure that represents the internal parameters of g). One 
possible such requirement/constraint would be that the value 
of a, some given internal parameter of g, should fall in some 
particular range (a > 10, for example). Meta-problem sce- 
narios and internal parameters is the subject of the next sub- 
section. 

We might contemplate a method by which to address the 
entire composite problem that consists of (a) optimizing the 
solution of the initial Type-G problem and (b) optimizing the 
solution of the meta problems in the infinite sequence men- 
tioned above. In pursuing this, we would naturally confront 
the question of whether it makes sense to try to apply such 
a search algorithm or method indefinitely to an infinite se- 
quence of problems of Type G as describe above. 

11.4.3. Approaching the G* Problem. 

This is moot, however, since in fact we seek not a theoreti- 
cal solution for this entire indefinitely compounded problem, 
but rather a feasible means of attacking a useful part of it. 
We alluded to a similar issue in the last paragraph of Sec- 
tion 6.1 (page 34), and indicated that, in avoiding a kind of 
infinite regression, a justifiable approach — 

1 . would first generate a set of data cases for the problem 
represented by the first element of the sequence. Each 
of the data cases would consist of 

(a) an actual or realistic problem scenario for the 
given problem and 

(b) the calculated optimal choice of the values of 
the internal parameters of the Type-G prob- 
lem for solving the problem scenario, where the 
optimal choice is discovered via an appropri- 
ate probabilistic search strategy (i.e., an evolu- 
tionary search strategy), and 

2 . would then use a hypersurface-fitting method to fit to 
the generated data cases an estimation function that, 
given an arbitrary problem scenario for the problem 
represented by the first element of the sequence, would 
return an estimate of the optimal choice of the values of 
the internal parameters of the Type-G problem for the 
problem scenario. 

The first part of the above approach is satisfied through 
the application of appropriately defined instances of a search 
algorithm — which will be specified below as an evolution- 
ary search algorithm. The second part of the above approach 
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is satisfied through a generalized version (the G** algorithm 
(see Subsection 11.5 (page 53))) of the methods and algo- 
rithms described in Section 7 (page 36). 

11.4.3.1. Internal Parameters of Type-G Problems. 

Each internal parameter 

ai,i G (l,...,len(a)} 

of Type-G problem ( 5 , 7 , v, t, a , / r , /test, fm, /c, tt) has an in- 
teger value that represents the number of new candidate so- 
lutions that will be added to the working population in each 
step respectively in each iteration of the steps listed in the 
definition of a G-algorithm (Algorithm 4 (page 49)). Since a 
problem scenario 7 ' for meta problem S' is a vector of con- 
straints on the solutions of the meta problem (that is, con- 
straints on the values of the internal parameters of the given 
Type-G problem), it may, without loss of generality, be as- 
sumed that all problem scenarios for all meta problems are 
identical, and further that every such constraint is simply that 
the value of the internal parameter must be nonnegative. In 
fact, this assumption will align with the proposition stated 
elsewhere that the constraints represented by a problem sce- 
nario should be as loose as possible so as to ensure the most 
thorough possible exploration of the solution space by the 
evolutionary search algorithm. 

11.4.3.2. Constructing Type-G Meta Problems. We 

now define a function that, given a problem scenario 
7 in Type-G problem domain S, returns the Type-G 
meta-problem scenario 7 ' in Type-G meta-problem do- 
main S', i.e., the problem of finding an optimal choice of 
the values of the internal parameters of p (the Type-G prob- 
lem of finding an optimal solution for the given problem 
scenario 7 ). 

Definition 140: 

Tnew-g ■ 0 X G — y G 3 

V(0 € N len ( a \p = (<5, 7 , v , T, a, f T , /test, / m , /c, tt)) e 
6 x G, 

Enew-g($> 9 ) = (S, 7, F 7", 9, / r , /test, fm, /c, 7 1 ")' 

F ncw . K , given a Type-G problem g and a vector 9 representing 
a choice of the values of the internal parameters of g, returns 
a new Type-G problem identical to g except that p’s internal 
parameters are replaced with 6. Note that 0, the set of all per- 
missible solutions for problems of Type G, includes permis- 
sible solutions for Type-G meta problems, and thus, a vector 
9 G N len ( a ) representing a choice of the values of the inter- 
nal parameters of g, and representing, therefore, a permissi- 
ble solution of the Type-G meta problem, belongs to 0. 

Definition 141: 

■Fmeta C G g 3 f G Fmeta => 


Vp = (S, 7, V, T, a, fr, /test, fm, fc, 7r) G G , 

9' = (<*', 7', v', t', a', f', //est, /„, /', tt') = f(g) <S> 

1. S' is the meta problem of optimizing the Type-G prob- 
lems for solving problem scenarios in 6, 

2. 7 ' 6 S' is the meta problem scenario of optimizing g, 

3. t' = T, 

4. / r G F ran[ ] omse i ec ti ()n [S ,7 ), 

5. /test = /test ° /g-execute 0 S new-g , 

6. fm € ^mutation {S', 'y 1 ), 

7. /c G F crosS over(^,7')- 

A function / that belongs to the set Fmkta will accept as in- 
put a Type-G problem g and return as output another Type-G 
problem for solving the meta problem of finding an optimal 
choice of the values of the internal parameters of g. 

A number of observations apply to the above definition 
in relation to its complexity, particularly as to its use in opti- 
mizing a G s problem as described below (Subsection 1 1.4.5). 
The complexity arises mainly from the definition of the fit- 
ness function /test’ which is the composition 7 of three other 
functions. In the Type-G meta problem g', the fitness func- 
tion /test is defined as p’s fitness function, / tes t , applied to the 
optimal solution obtained by executing Algorithm 4 against 
the modified version of g, i.e., the version of g obtained by 
replacing the existing choice of the values of p’s internal pa- 
rameters, a, with 9, the given candidate choice of the val- 
ues of the internal parameters of p. Thus, since the execution 
of Algorithm 4 against the modified version of p takes place 
during the process of running the fitness function of the Type- 
G meta problem, this fitness function does the heavy lifting 
in executing Algorithm 4 against a Type-G meta problem, as 
will be explained in Subsection 1 1.4.5. 

While the insight that was afforded in Section 10.5 
(page 44) into the effect of changing the value of any 
given internal parameter may be relevant to Type-G prob- 
lems, we do not pursue the idea of modeling the perfor- 
mance of the G-algorithm (Algorithm 4). Instead, it can 
be noted that a direct approach would consist of the im- 
mediate application of some / G F META , where, Vp G G, 
the optimal choice of the values of the internal parame- 
ters of p is simply 

/g-execute (/($ 0) 

An extension of this approach will be described in Subsec- 
tion 1 1.4.5 relative to a chain of Type-G meta problems. 


7 In mathematics, “function composition” (indicated by the symbol o) 
refers to the use of the output of one function as the input for another. 
See Definition 12 (page 17). 
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11.4.4. The G 6 Problem: A Chain of Ttype-G Meta 
Problems. 

We proceed to consider the generalization of the concepts 
addressed in the main body of this paper, namely, the prob- 
lem of ( 1 ) how to choose the values of the internal param- 
eters of the Type-G problem to maximize the performance 
of the G-algorithm in a fielded system, (2) how to optimize 
the internal parameters of the Type-G problem of optimizing 
that Type-G problem, (3) how to optimize the Type-G prob- 
lem that does this, etc., indefinitely. We refer to this problem 
as the G* problem. Note that its rather theoretical underly- 
ing idea will not preclude a treatment of the G* problem sup- 
porting practicality and feasibility. 

Definition 142 (G* Problem): 

G* C S *(G) 9 £ e G* =► 

1 . 3g € G 9 g = £o, 

2. 3f e -Fmeta 9 

Vj € {1, ... , len(£) — l},£j = /(£j_i) 

G* is the set of all possible G # problems. Each element ex- 
cept the first element of the sequence £ e G* is a Type-G 
meta problem of optimizing its predecessor. £ 0 , the first ele- 
ment of £, is a Type-G problem representing the base case for 
the recursive process that takes place when one of its succes- 
sors in £ is executed. By Definition 136, £o represents some 
Type-G problem g = (<S, 7 , v, r, a, f T , / tes t, fm, fe, tt) € G 
for finding an optimum solution for problem scenario 7 € <5. 

11.4.5. Optimized G # Problem. 

Definition 143 (Optimized G* Problem): 

A G # problem £ € G* is said to be optimized if and only 
if Algorithm 4 has been run against the Type-G meta prob- 
lem £i en ({)— l’ resulting, recursively, in the replacement, in 
Type-G problems £j,j 6 {0, . . . ,len(£) - 2}, of the val- 
ues of their internal parameters with the optimal values com- 
puted by recursively executing Algorithm 4 against each ele- 
ment of £ starting with its last element (£i en (f)-i)- 

11.4.5.1. Explanation of Recursive Optimization in the 

G # Problem. Algorithm 4 is recursive by virtue of the def- 
inition of the fitness function of a Type-G meta problem (see 
remarks under Definition 141). This fact enables the opti- 
mization of the G& problem, where the entire chain (i.e., 
sequence) of Type-G meta problems described in Defini- 
tion 142 will be optimized by application of the algorithm 
to the last element of the chain. 

By way of further explanation, note that some prescribed 
function / € Emeta, given some element & in the chain (se- 


quence) £ as input, will have produced the Type-G meta prob- 
lem 

£i+i = (<*',7 

for optimizing By Definition 141, 7' 6 S ' is the meta prob- 
lem scenario of optimizing target Type-G problem &. Apply- 
ing Algorithm 4 to £i+i will take the following course: 

1. Step 1 executes the random-selection function / r ' and 
returns II, a set of candidate solutions of problem sce- 
nario 7 ', the problem of optimizing the choice of the in- 
ternal parameters of Type-G problem £j. Thus, II is a set 
of vectors representing possible such choices, i.e., solu- 
tions of problem scenario 7 '. 

2. Step 2a executes the function kE steps with the ordered 
pair (II, £i+i) as input and then sets II' to the value re- 
turned. As Wsfcps executes, the composite function /test 
will be used to test the candidate solutions individu- 
ally. Since by Definition 141, /test executes the func- 
tion /g-execute with the Type-G problem & as the input, 
then, by Definition 139, Algorithm 4 will itself be in- 
voked again part-way through the steps of the self-same 
algorithm, thus resulting in recursion. 

Step 2 of Algorithm 4 progresses through successive gen- 
erations of candidate solutions, ultimately ending with either 
the expiration of the allowed run time v' or the discovery of 
a “good enough” solution according to the parameter r\ and 
the best solution found during this iterative search process is 
returned at the termination of step 2 . 

It may be helpful to elaborate somewhat on the use, in the 
definition of the G* problem (Definition 142), of the function 
/ £ -Fmeta, which, in constructing £, produces, for each el- 
ement £*, the Type-G meta problem £ i+ i that will be solved 
via Algorithm 4. The key part of the definition of / e Emeta 
is the composite function /test- When invoked during the ex- 
ecution of the function W steps against the set II of candidate 
solutions, / 4 st first applies the function F new . g to the candi- 
date Type-G problem given as input along with the candidate 
solution (a choice, 7 r (see step 2b of Algorithm 4), of the val- 
ues of the Type-G problem’s internal parameters), producing 
as output a modified version of the target Type-G problem, 
with 7 r in place of the original vector a of internal parame- 
ters. This output from F new . g (i.e., the modified version of the 
target Type-G problem) is used next (according to the defini- 
tion of / 4 s t as the composite function / tcst o /g. exe cute 0 F ncw .g) 
as input to the function /g-execute. whose output (the optimal 
solution returned from running Algorithm 4 against the mod- 
ified version of the target Type-G problem) is used as input to 
the fitness function / tes t, which is the fitness function of the 
target Type-G problem itself. 

But the recursive nature of Algorithm 4, when used on a 
member of a chain of Type-G meta problems, means that the 
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above sequence of operations continues until the base case 
is reached in the chain (i.e., the first element of the chain), 
where the target Type-G problem, by the definition of a G 3 
problem (Definition 142), is not a Type-G meta problem (i.e., 
the problem scenario is not to optimize a predecessor in £) 
and, in completing the recursive process, the fitness of the so- 
lution returned from applying Algorithm 4 against it is used 
in following in reverse order the progression of operations 
that took place in the recursive chain ending at the base case. 

11.4.5.2. Limits on Run Time. Optimizing a G 3 problem 
£ e G*, involving recursion during the execution of Al- 
gorithm 4, in which each new recursive step involves the 
full evolutionaiy search process that itself is a repetitive 
process of evolving a population of solutions through per- 
haps many generations, is easily seen to be very demanding 
computationally — the more so the longer the sequence £. 

From an implementer’s point of view, an early question 
would concern how much ran time to allow for the optimiza- 
tion of £ (see Definition 143). That is, suppose i £ N+ is the 
index of a Type-G meta problem in £, and 

& = v ' , t', a ', /;, /^, tt') 

Then what value should v' (i.e., &[3]) have? 

Experience with an evolutionary-search application for a 
given problem domain will eventually teach the practitioner 
the empirical fact that runs of the application will process 
some typical number ni of generations before reaching the 
optimal solution. For argumentation purposes, we assume 
that the idea of the existence of such a typical value applies 
in the case of a G 3 -problem optimization. Thus, if 

£o =9 = (5, 7) *7 T, a, f T , /test, /m, /c, 7r) £ G 

(where v, the run time of g (or at least its typical value), will 
also be learned from experience) then the run time expected 
for the execution of the Type-G meta problem will be given 
by the relation 

v' = n\v (9) 

Hence, given the simplifying assumption that each evolution- 
ary search will (with fixed computational resources) process 
ni generations before reaching the optimal solution, the con- 
clusion is that the computational burden increases exponen- 
tially with the size of the G 3 problem (eG* (i.e., exponen- 
tially with the length of £). 

The assumption regarding m could be modified to reflect 
that undoubtedly the “typical” number of generations for the 
runs of the application program varies as a function of the in- 
dex i into the sequence £. That is, n \ : N -> N. If we now 
consider that the allowed run time is a sequence fyj ) (where 
Vi = £j[3]) we can restate Equation 9: 

v i+ 1 = ni(i + 1 )vi (10) 


Despite the fact that no principles support the a priori 
choice of an optimal vector of the values of the internal pa- 
rameters of the base case (i.e., for the Type-G problem £ 0 ), 
we must allow for the possibility that Type-G meta problems 
may all have the same optimal vector of the values of their in- 
ternal parameters. In this circumstance, after computationally 
establishing this optimal vector for ^i, it would render unnec- 
essary any further computation to optimize any of the subse- 
quent Type-G meta problems in £. Therefore, the question 
of run-time limits becomes moot in this circumstance, but 
whether this circumstance actually prevails in general would 
have little chance of resolution short of experimentation, and 
so in the meantime it must be categorized as speculative. 

Such experimentation could hardly be conducted in the 
first place upon any assumption other than the one repre- 
sented by Equation 10 (absent any a priori knowledge to the 
contrary) and thus is established the usefulness of the forego- 
ing analysis. 

11.4.6. Practical Stopping Point in the G 3 Algorithm. 

As indicated previously (Subsection 1 1 .4.3 (page 50)), how- 
ever, the purpose of having an optimized G 3 problem is not 
to have some lengthy sequence of Type-G meta problems op- 
timized, for which the necessary computational power would 
(as shown in the preceding paragraph) increase exponentially 
with the length of the sequence. Indeed, reflecting the au- 
thor’s judgment, the requirement for practical operational use 
would be much more modest (see further remarks in Para- 
graph 11.5.1.3), and would afford adequate advantage with 
the sequence £ having length 2, with a single Type-G meta 
problem fy to optimize the Type-G problem £ 0 for solving a 
given target problem scenario. Thus, executing Algorithm 4 
against Type-G problem fy would optimize the internal pa- 
rameters of the Type-G problem £ 0 , supporting the practical 
approaches to be described next for the use of the above G 3 
method and algorithm. 

11.5. Overall Optimization: Problem. 

11.5.1. The Final Issue. 

The final issue to be addressed relative to the generalization 
of the concepts covered in the main body of this paper per- 
tains to the practicality of the G 3 method and algorithm for 
operational use. 

11.5.1.1. Internal Parameters Estimation Functions. 

Various relevant considerations were presented in Sec- 
tion 7 (page 36) in discussing approaches for obtaining 
efficient estimation functions. In the present context, an es- 
timation function, given a problem scenario, would return 
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an estimated optimal choice of the values of the inter- 
nal parameters of the Type-G problem for solving the 
given problem scenario. (In the earlier discussion, the con- 
text was the NASA space-data communications scheduling 
problem, whereas here we are in a more abstract discus- 
sion of optimization of a Type-G problem.) 

11.5.1.2. Concerning the Goal. As in Section 7 
(page 36), our goal in the present section is to maxi- 
mize the practicality of the overall general optimization 
methods. We address the problem, which we will re- 
fer to as the G®® problem, of devising a means for efficiently 
estimating an optimal choice of the values of a Type-G prob- 
lem’s internal parameters for any given new problem sce- 
nario so that it will not be necessary each time to use the 
G® algorithm to perform the whole iterative (and computa- 
tionally expensive) process of solving the internal parame- 
ter optimization problem. Clearly, the overall optimization 
problem is computationally very demanding, and con- 
sequently the method and algorithm described above for 
solving the G® problem would not be advantageous to use op- 
erationally for every new problem scenario. (To be sure, such 
a burdensome strategy would quickly be seen to be coun- 
terproductive, since an optimal solution for the given prob- 
lem scenario would be reached anyway during the very first 
iteration of the effort to solve the G® problem, thus obvi- 
ating any additional effort in that direction.) However, the 
G® method and algorithm will support the goal of solv- 
ing the G®® problem of deriving an estimation function 
that, given an arbitrary problem scenario for the given tar- 
get problem domain <5 e A, would, at low cost, return an 
estimated optimal choice of the values of the internal pa- 
rameters of the Type-G problem for solving that prob- 
lem scenario. The objective, then, is to specify an estimation 
method/algorithm that uses (abstracted and computation- 
ally inexpensive) information about the given problem 
scenario itself. 

11.5.1.3. A Judicious Stopping Point Although the 
method and algorithm specified above for addressing the G® 
problem £ e G* (see Definition 142) allowed for any ar- 
bitrary number of Type-G meta problems listed in the 
sequence £, the author considers (as indicated in Subsec- 
tion 11.4.6) that, for practical operations using the meth- 
ods and algorithms disclosed herein, the length of £ 
would be 2, so that Type-G problem (i.e., the last ele- 
ment of £) would be the Type-G meta problem for optimiz- 
ing £ 0 for solving the initial problem scenario £o[2] (note 
that £ 0 is a tuple, whose second element, £ 0 [2], is a prob- 
lem scenario 7). Indeed, upon practical considerations of 
computational feasibility as opposed to purely theoret- 


ical considerations, it is unlikely that any value greater 
than 1 for the index into £ could be entertained at all, and 
so in this sense the G® algorithm is academic. In the dis- 
cussion that follows, it will be included in the process 
for implementing the G®® algorithm, with the understand- 
ing that, in use, there would be only one level of Type-G 
problem optimization (corresponding to a single applica- 
tion of Type-G problem optimization) representing a kind of 
minimal use (and perhaps the only feasible use, as will be ex- 
plained) of the G* algorithm). 

The question of the efficiency of the Type-G problem- 
optimization process would itself involve the question of how 
to set the values of the internal parameters of £1, the Type-G 
meta problem for solving the meta problem scenario £1 [2] . 
This is an open question, although, since all of the Type- 
G meta problems have identical problem scenarios (i.e., all 
of the constraints they specify are, by assumption (see Para- 
graph 11.4.3.1), the same), it cannot be dismissed that (as 
discussed in Paragraph 1 1 .4.5.2) the optimal choice of the 
values of the internal parameters of all of the Type-G meta 
problems would be the same or at least nearly the same. 
Whether a substantial improvement in performance might oc- 
cur for small changes in the values of the internal parameters 
is not known, but seems unlikely over a wide range of possi- 
ble choices; in other words, performance may be insensitive 
to the choice, and, consequently, the effort to optimize the 
Type-G meta problems listed in £ may not have much justifi- 
cation. As to choosing the values of the internal parameters of 
a Type-G meta problem, the only guidance that could be of- 
fered to a developer (especially one who ventures to extend 
the Type-G problem optimization to any level correspond- 
ing to a value greater than 1 for the index into £, by which 
to specify the Type-G meta problem to initiate the optimiza- 
tion of the G® problem) would be a matter of informed judg- 
ment at best. 

11.5.1.4. Challenges From the Real World. It should be 
well noted that real-world problem domains of Type G typ- 
ically entail significant complexities that inevitably would 
translate into challenges in using the methods to be presented. 
An estimation function, even if derivable in principle, may 
be difficult to obtain within realistic limits on computing re- 
sources (see also the remarks in Section 7.4 (page 38) and 
Subsection 1 1.4.6 (page 53)). The approaches to be described 
for solving the G®® problem will produce results (i.e, will pro- 
duce instances of estimation functions), but the approaches 
assume a selection of real-world input data to which, in ef- 
fect, a model will be fitted (see the outline of the approach 
given in Subsection 11.4.3 (page 50)). The accuracy of the 
derived estimation functions will be directly related not only 
to the shrewdness of the choices that determine the form or 
architecture of the model, but also to the selected input data 
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to which the model will be fitted, i.e., the number of pre- 
computed data points and their distribution across the so- 
lution space. The required accuracy of the derived estima- 
tion functions may require a significant number of precom- 
puted data points, and correspondingly significant comput- 
ing resources [23]. Further, since the accuracy metric un- 
doubtedly would exhibit asymptotic behavior in relation to 
the number of precomputed data points, and since the asymp- 
tote is not known in advance, even more computation would 
be needed to gain the assurance of any prescribed accu- 
racy. Thus, the real-world challenges in using the methods 
to be described would be considerable. However, the meth- 
ods can be expected to achieve the objective mentioned in 
Paragraph 11.5.1.2 (page 54) given a reasonably tame rela- 
tionship between the independent variable (the problem sce- 
nario (or rather its characterization (see Paragraph 1 1.5.1.5))) 
and the dependent variable (the optimal choice of the values 
of the internal parameters of the Type-G problem for solv- 
ing the problem scenario). The tameness of this relationship 
may be expected to be target-problem dependent, but an in- 
dependent means of determining the tameness in advance is 
unknown — although, reasonably, some probabilistic method 
would be strongly indicated (if not unavoidable). 

11.5.1.5. Characterization Functions. The approaches 
described in Section 7 relied upon the concept of a 
problem-scenario characterization function — which is a con- 
cept also involved in the approaches described in the fol- 
lowing paragraphs concerning mechanisms for estimating 
optimal choices of the values of the internal parame- 
ters of Type-G problems. The characterization function is 
intended to be a computationally inexpensive means of dis- 
tinguishing between problem scenarios in terms that are 
relevant to the efficiency of the evolutionary search meth- 
ods that will be used in solving arbitrary problem scenarios 
in the given Type-G problem domain. The efficiency of the 
search methods that we disclose herein is related to (among 
possibly many other things) the sizes of the data struc- 
tures that represent the elements of the problem scenario: by 
Definition 124 (page 46), a problem scenario is a finite se- 
quence each element of which is a finite data structure. In the 
case of the problem domain of scheduling space-data com- 
munications (see Section 7 (page 36)), each of these data 
structures was a set, and the sizes of all of the data struc- 
tures listed in a given problem scenario were used as the 
elements of the vector returned by the characterization func- 
tion (Definition 123 (page 36)). Partly for reasons of 
tractability and operational efficiency, we elect to use a simi- 
lar scheme here. 

We proceed by specifying, in the context of Type-G 
problem domains, the concept of a problem scenario- 
characterization function, noting from Definition 129 


(page 46) that, for a given target problem domain S of Type 
G, there exists a positive integer k p = A din , (5) such that 
all problem scenarios 7 G 5 have length k p , and, thus, ev- 
ery problem scenario y e 6 has a k p -dimensional characteri- 
zation 

c G N fcp 

For the problem, the characterization was defined so that 
Vj G {1, . . . , k p }, cj was the size of the finite data structure 
7 j (see Definition 123 (page 36)). For the generalized prob- 
lem of Type G, the definition of the characterization func- 
tions must be somewhat generalized and must accommodate 
Type-G meta problems. 

Definition 144: D 0 = {x : 3n G N B x G N"} 

D 0 is the set of all tuples whose elements are integers. Each 
problem- scenario characterization is a member of D 0 , as is 
each choice of (i.e., each vector that represents) the values of 
the internal parameters of a Type-G problem. 

Definition 145 (Problem-Scenario-Characterization Func- 
tion for Given Problem Domain): 

A: A ->• p(D^ xr ) 9 

V8 G A, A G A(S) =► V7 G S, \{5,y) G 

A(8) returns a set of characterization functions for the prob- 
lem domain 5. 

11.5.2. Regression Methods for Solving the Problem 

Deriving an estimation function /estimation that returns an es- 
timate of the optimal choice of the values of the internal pa- 
rameters of a Type-G problem may be accomplished through 
the application of some form of regression technology [15]. 
There are several of these technologies that potentially would 
be applicable, including: 

• Artificial Neural Networks (ANN) 

• Evolutionary Search 

• Support Vector Machines 

• Baysian Networks 

The estimation function to be derived is imagined (with 
the risk of oversimplification) as a hypersurface whose do- 
main (consisting of the values of the independent variable) is 
the set of all possible problem scenarios (or, rather, their char- 
acterizations) and whose codomain (consisting of the val- 
ues of the dependent variable) is the set of estimated optimal 
choices of the values of the internal parameters of the Type-G 
problems for solving problem scenarios in target problem do- 
main 6. A data regression approach as identified above repre- 
sents a kind of hypersurface-fitting technique, as mentioned 
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in the discussion in Subsection 7.2 (page 37), which con- 
cerned a method for scheduling-algorithm optimization. 

It should be reiterated that applying any of the indicated 
regression technologies would be subject to cautions simi- 
lar to the ones stated earlier (Subsection 7.4 (page 38) and 
Paragraph 11.5.1.4 (page 54))). However, the evolutionary- 
search approach, in particular (as one of the available regres- 
sion technologies), may be accomplished through the appli- 
cation of the techniques required for the application of the G- 
algorithm described herein: it will be seen that the problem 
at hand (i.e., the problem of deriving the optimal-intemal- 
parameters-estimation function) itself can be formulated as a 
problem of Type G and therefore the application of the G- 
algorithm (i.e., Algorithm 4) would be sufficient to obtain a 
solution, although the computing resources required for a so- 
lution may present an issue to be investigated by compar- 
ing this approach with others based on alternative regression 
technologies. 

Regardless of which regression technology is employed, 
the derived estimation function would have value in an op- 
erational system in terms of maximizing the performance 
of the G-algorithm. For any given problem scenario to be 
solved by the system, the values of the internal parameters of 
the Type-G problem would first be adjusted according to the 
estimate that would be generated by the derived estimation 
function. The process for using the derived estimation func- 
tion operationally will be further specified in Subsection 11.7 
(page 60). 

The objective of applying a regression technology to a G*" 
problem is to derive an estimation function /estimation from a 
given known data set Q C D^, where for each (c, e) G Q, c 
is a characterization of a problem scenario and e is a corre- 
sponding calculated optimal choice of the values of the inter- 
nal parameters of the Type-G problem for solving the prob- 
lem scenario. 

11.5.3. Functions That Model a Given Data Set. 

It is assumed that at least one data-regression technology 
will have been selected for application in solving G^ prob- 
lems. Solving a given G t,tt problem would consist of apply- 
ing the selected data-regression technology to an appropri- 
ate precomputed data set Q to derive a function that mod- 
els Q. The derived function may then be used to estimate the 
value of the dependent variable for any given value of the in- 
dependent variable. The value of the independent variable for 
a given G** problem would be a tuple representing the char- 
acterization of the given problem scenario, and the value of 
the dependent variable would be a tuple representing the es- 
timated optimal choice of the values of the internal param- 
eters of the Type-G problem for solving the given problem 
scenario. 


Definition 146 (Set of Selected Data-Regression Technolo- 
gies): 

A r = {a: a is a data-regression technology}. 

If not otherwise stipulated, it will be understood that a data- 
regression technology a regr € A r has been selected for use in 
solving GM problems. 

Definition 147 (Functions That Model a Given Data Set): 
A function / G D®° is said to model QCD§ if and only if 

(c,e) G Q =>• /(c) = e 

Note that / in the above definition is a subset of Dq. 

Definition 148: 

T: P (D^D 0 d °9VQCD§, 

Y(Q) is a model of Q derived by applying data-regression 
technology a regr to the data set Q. 

Thus, if T (Q) models Q, then V(c, e) GQ,Y(Q)(c) = e. 

Definition 149 (Training-Data Sets): 

D: Ax p(r) x codomain(A) -> p(Dq) b 

v(s,BC5, A G A(<5)) G A x p(r) x codomain(A), 
VQ G D(6,B,X),(c,e) G Q =>• 

1 . £ 5 , 

2. 3 optimized G # problem (gG'3 

(a) £ 0 = ($,7> •>•><*> •>•>•>•>•) G (-'scenario (^) 7)) 

(b) c=X(5, 7 ), and 

(c) e = a = f 0 [5] 

D represents the set of all possible training-data sets for G^ 
problems (to be described in the next section). Each such data 
set Q will be assumed to comprise actual calculated data. 
Each member of Q, then, is an ordered pair (c, e), where 
c is the calculated characterization of some realistic/actual 
problem scenario drawn from the given set B, and, for a cor- 
responding G* problem £ that has been optimized by run- 
ning Algorithm 4 (page 49) (see Definition 143 (page 52)), 
e is the optimal choice of the values of the internal parame- 
ters of the Type-G problem £ 0 . It is assumed that each such 
training-data set Q can be modeled by applying to Q the se- 
lected data-regression technology o regr . The derived model is 
identified as an estimation function that, given the character- 
ization of an arbitrary problem scenario 7 in the given prob- 
lem domain 5, will return the estimated optimal choice of the 
values of the internal parameters of the Type-G problem for 
solving 7 . 

11.5.4. The Problem. 

Definition 150 (G^ Problem): 
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A tuple 

(ji € A, B C S, A £ A(<5), /estimation^ 

is said to be a G tttt problem if and only if 

1. each member of B is an actual/realistic problem sce- 
nario, 

2. 3Q £ D(S,B,X ) 9 /estimation = 'T(Q). 

11.5.5. The G** Algorithm Employing Data-Regression 
Technology. 

The essential steps in applying a data-regression approach in 
the problem are as follows: 

Algorithm 5 (G^ Algorithm Employing Data- Regression): 

Given: 

• 6 e A, 

• B C 6 is a set of actual/realistic problem scenarios se- 
lected from the set S, 

• A € A(6), 

(Note: The results of running an implementation of the 
present algorithm are highly dependent on the num- 
ber and distribution of the scenarios in B. If the accuracy 
of the estimation function generated by the implementa- 
tion is not deemed adequate, then these scenarios would 
need to be revised to improve their solution- space cover- 
age and used in a fresh rerun.) 

Perform the following steps: 

1. Let Q £ D(6, B , A). 

2. Perform data-regression using the training-data set Q, 
resulting in the determination of a function that best fits 
the members of Q. That is, let /estimation = T(Q). 

3. If step 2 (the data-regression step) succeeds, then form 
the G^ Problem 

(5, B, A, /estimation) 

and exit indicating success. If data regression fails, then 
exit indicating failure, calling upon the user to alter the 
given set B of actual/realistic problem scenarios (e.g., 
by increasing their number or variety) (noting that this 
alteration gives an altered G^ problem) and rerun the 
algorithm. 

Step 1 above will, in general, involve significant computation 
of a recursive nature using Algorithm 4 (page 49) to derive 
the data set Q (see Definition 149 (page 56)). 


11.6. Implementation Process 

Implementation of the generalized methods and algorithms 
described in this Appendix may be straightforward (not to 
say trivial) for some problem domains but likely would be 
challenging for others. For the sake of completeness of this 
disclosure, we now delineate a nominal implementation pro- 
cess, which would be applicable to all implementation ef- 
forts, but which does not preclude appropriate variations or 
adaptations for particular cases. 

11.6.1. The Basic Implementation Alternatives. 

The minimum implementation effort would have the goal of 
building a system that implements a Type-G problem 

9 = (s, 7, V, T, a, f r , /test, f m , f e , 7T ) 6 G 

configured initially with arbitrary (non-optimized) choices of 
the values of the internal parameters a for solving the given 
problem scenario j £ S. A more ambitious possible effort 
would have this minimal implementation as one goal, and 
would have the further goal of implementing a system for 
solving the G #tt problem for the same problem domain 6 £ A. 

In either case, the implemented system will produce opti- 
mal solutions for problem scenarios in the target domain 6. 
The system developed in the more ambitious possible effort 
mentioned above would be expected to perform more effi- 
ciently in the routine operations mode — at the cost of the ef- 
fort to solve the G ## problem to derive the estimation function 
(see Subsection 1 1 .5) for estimating, for each given problem 
scenario 7 , the optimal choice of the values of the internal pa- 
rameters of g £ ^scenario ( 6 , 7 ). 

The general implementation approach that will be de- 
scribed below in detail is first to implement modules sepa- 
rately, and then to integrate those modules, together with all 
other necessary modules (e.g., interfaces with users and an- 
cillary systems), into the overall fielded system, with appro- 
priate testing, documentation, etc. 

11.6.2. The First Implementation Alternative (Basic 
Implementation of the G- Algorithm). 

In the first alternative (i.e., the basic implementation of the 
G-algorithm), the implementation steps follow the first few 
steps enumerated in the G-algorithm specification (Algo- 
rithm 4 (page 49)). A subsystem that is capable of creating 
and solving a Type-G problem 

9 = (£, 7, v , T, a, fr, /test, fm, fc, ? t) £ G 

would be constructed by means of the following process: 
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Process 2 (Process for Implementation, First Alterna- 
tive (Basic Implementation for Creating and Solving a 
Type-G Problem)): 

Given: 

• S £ A 

• 7 e <5 

Perform the following steps: 

1. Implementation steps for a subsystem for creating a 
Type-G problem for solving 7 e 6. 

(a) Develop a module that supports the cre- 
ation/setting of — 

i. v £ N+, a value that represents the run-time 
limit in units of seconds. 

ii. t £ IK, a small nonnegative value to repre- 
sent a policy or judgment as to how close to 
perfect a solution must be (i.e., how close a 
solution’s fitness must be to unity) to be con- 
sidered “good enough” to exit the algorithm. 
This value normally would be small enough 
(0, say) to ensure that the algorithm always 
ran for the maximum allowed run time v. 

iii. a £ D 0 , the vector representing the user’s 
initial choice of the values of the internal pa- 
rameters of g, with len(a) = A dim (6). 

(b) Develop a module that embodies a random- 
selection function / r £ f^randomselection 7 ) 

(c) Develop a module that embodies a fitness func- 
tion /test € Ditness(^) T) - 

(d) Develop a module that embodies a genetic- 
mutation function f m £ Station ( 6 , 7 )). 

(e) Develop a module that embodies a genetic- 
crossover function / c £ F CTOSSOVer (< 5 , 7 )). 

(f) Develop a module that supports the creation of a 
place-holder data structure tt representing an ar- 
bitrary member Of ©scenario (^7)- 

(g) Develop a module that supports the creation of 
the data structure 

g = (6, 7 , V , T, a, fr , /test, fm, fc, 7r) € 

^scenario (^, 7) 

according to Definition 136 (page 48) and Defini- 
tion 137 (page 49) 

2. Implementation steps for a subsystem embodying 
Algorithm 4: 

(a) Develop a module that embodies the function 
Wsteps according to Definition 138 (page 49), in- 
corporating the module developed in step lg. 


(b) Develop a module to capture II, the output of 
function f T when given the input equal to 

j£{l,...,len(a)} 

(c) Develop a module to capture 11', the out- 
put of function W^teps (the module devel- 
oped in step 2 a) when given the ordered pair 
(II, g) as input, where II and g are the out- 
puts of the modules developed in steps 2 b 
(for for creating a random-selection func- 
tion fr £ F ramlomsclcction (3,'Y) (for a given (5, 7 )) 
and lg (for for creating a Type-G problem), re- 
spectively. 

(d) Develop a module to find a member n 1 £ II' 9 
C e IT => /fc st(C) > /test(7r')» where n ' is fo e 
set captured by executing the module developed 
in step 2 c. 

(e) Develop a module that sets 7 r to the output, n', 
from executing the module developed in step 2 d. 

(f) Develop a module that sets II to the output, II', 
from executing the module developed in step 2 c. 

(g) Develop a module that performs the test f t {ir) < 
1 + t and tests whether the elapsed run time ex- 
ceeds v, and if either test is affirmative, then exits, 
returning the value n, and, if otherwise, then re- 
sumes execution of the sequence of modules de- 
veloped in steps 2 c through 2 g. 

3. Develop a module that embodies the function /.-execute, 
which in turn will incorporate the module embodying 
Algorithm 4 developed in step 2. 

4. Develop a module that (a) executes, with g £ G as in- 
put, the module embodying the function /.-execute devel- 
oped in step 3 for a given Type-G problem and (b) re- 
turns the optimal solution of g. 

5. Perform system integration and testing of the modules 
developed as specified above, along with all other nec- 
essary modules (e.g., user interfaces). 

Once implemented, the fielded system would be used op- 
erationally according to the following straightforward pro- 
cess: 

Process 3 (Process for Operational Use of Implementa- 
tion Under First Alternative (Basic Implementation for 
Creating and Solving a Type-G Problem)): 

Given: 

• S £ A 

• 7 £ S 
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Perform the following steps: 

1. Prepare all input data required for a run of the system 
developed in Process 2 (page 58) (including the target 
problem scenario and other inputs as required by the G- 
algorithm specification (Algorithm 4 (page 49))). 

2. Initiate a run of the system with the stipulated inputs 
and capture output upon termination of run. The out- 
put is an optimal solution for the given problem sce- 
nario 7 (see remarks in Section 2.4.7 on page 13 con- 
cerning the concept of “optimum”). 

11.6.3. The Second Implementation Alternative 
(Implementation of the G^ Algorithm). 

The second implementation alternative incorporates all of the 
steps in the first alternative as described above (Process 2 
(page 58)), which produces an implementation of a system 
that can create and solve a Type-G problem 

(8, 7, V, T, a, fr, /test, /m, /c, n) £ G 

The additional steps required in the second implementation 
alternative will be described next, and have the objective of 
maximizing the performance of the fielded system over the 
broad range of possible problem scenarios. This objective 
is achieved by implementing the G** algorithm (see Algo- 
rithm 5 (page 57), which incorporates the G # problem opti- 
mization (see Definition 143 (page 52)), which, in turn, in- 
corporates the G-algorithm (Algorithm 4 (page 49)). 

It is necessary, then, to describe implementation steps for 
the G # problem optimization, as well as the G*' algorithm). 

Process 4 (Process for Implementation, Second Alter- 
native (Implementation of Algorithm (Algorithm 5 
(page 57))): 

Given: 

• 5 e A 

Perform the following steps: 

1. Implementation Steps for Support-Modules for 
Type-G Problem Optimization. Supporting mod- 
ules in an implementation of a Type-G problem- 
optimization function will be constructed by means of 
the following steps: 

(a) Develop (see implementation steps specified in 
Process 2 (page 58)), or incorporate, a module 
that supports the creation and solving of a Type-G 
problem 

g = (8, 7, V, T, a , f T , /test, /m, /c, tt) € G. 

Note that this module incorporates (from step 3 
of Process 2) a module that implements the G- 
algorithm-execution function / g . e xe cute (see Defi- 
nition 139). 


(b) Develop a module that embodies the function 
-Fnew-g (see Definition 140 (page 51)) 

(c) Develop a module that embodies the definition of 
a function in the set -Fmeta that, given a Type-G 
problem 

g = ( 8 , 7 , v, t, a , / r , / tes t, /m, /c, ^ r) e G 

returns a Type-G meta problem g' (see Def- 
inition 141 (page 51) in Paragraph 11.4.3.1 
(page 51)). 

2. Implementation Steps for a Subsystem that Sup- 
ports the Creation of a Module that Embodies the 
G s Problem Optimization. A subsystem that supports 
the creation and optimization of a G* problem ( £ G* 
(Definition 142) (where len(£) = 2, in accord with 
the position taken in Subsection 1 1 .4.6 (page 53) and 
in Paragraph 11.5.1.3 (page 54)) will result from inte- 
grating modules constructed by means of the following 
steps: 

(a) Develop or incorporate a module that implements 
the G-algorithm-execution function / g . e xe cute (see 
step 3 of Process 2). 

(b) Develop a module that creates the G # problem 
£ £ G*, with £ 0 = 9, in accordance with Defi- 
nition 142 (page 52), where 

g = (8, 7 , v, r, a, f T , /test, / m , / c , tt) e G 
is a given Type-G problem. This module incorpo- 
rates the module developed in step lc, which is 
an implementation of a function in F META , which 
in turn incorporates the module developed or in- 
corporated in step 2 a for the function / g<xe cute- 

(c) Develop a module that incorporates the module 
developed in step 2 of Process 2 and supports 
the execution of Algorithm 4 against the Type-G 
problem £i e „(f)_i, which results in the optimized 
version of the G# problem £ £ G* (see Defini- 
tion 143 (page 52)). 

3. Implementation Steps for the G^ Algorithm 
Via Data-Regression. A system incorporating a 
data-regression approach for solving a G #|t prob- 
lem (S,B,X, /estimation) will be constructed by means 
of the following steps: 

Given: 

8 e A 

Perform the following steps: 

(a) Develop a module that embodies a problem- 
scenario characterization function A e A((>) (see 
Definition 145 (page 55)). 
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(b) Develop a module to support the creation ofBC 
S consisting of actual/realistic problem scenarios 
in 5. 

(c) Incorporate a module supporting the creation of 
Type-G problems for problem scenarios for the 
given target problem domain S (see step la above 
and Subsection 11.6.2). 

(d) Develop or incorporate a module that em- 
bodies the function D (see Definition 149 
(page 56)), which incorporates the module de- 
veloped in step 2 c for optimizing a G e prob- 
lem. 

(e) Develop or incorporate a module that embodies 
the function T (see Definition 148 (page 56)), 
which implements the data regression technol- 
ogy «regr (see explanation below Definition 146 
(page 56)), and which incorporates the modules 
developed in steps 3a and la. 

(f) Develop a module that executes the module de- 
veloped in step 3e and captures the output (i.e., 
the function /estimation = T(Q), where Q £ 
D(5,B, A)). 

(g) Develop a module that 

i. executes the module developed in step 3a 
and retains the function A 

ii. executes the module developed in step 3b 
and retains the set B. 

iii. executes the module developed in step 3d 
and retains the set Q £ D(6,B, A) . 

iv. executes the module developed in step 3f 
and retains the function /estimation = T (Q) 

v. if the data-regression step 3(g)iv is success- 
ful, then constructs the G^ problem 

G A, B C S, A £ A (5), /estimation) 
and exits indicating success; otherwise, exits 
indicating failure and calling upon the user 
to start a new run, ensuring that the set B re- 
tained from step 3(g)ii is more appropriate 
in solution-space coverage. 

4. System Integration. Perform system integration and 
testing of the modules developed as specified above, 
along with all other necessary modules (e.g., user in- 
terfaces) for the final fielded system. 

The final result of the implementation steps given above 
would be a system consisting of (a) a subsystem by which 
a Type-G problem can be used to produce optimal solutions 
for any given problem scenario and (b) a subsystem by which 
the optimal choice of the values of the internal parameters of 


a given Type-G problem can be estimated for arbitrary prob- 
lem scenarios to enable the most efficient overall possible op- 
eration of the system for arbitrary problem scenarios. 

For reasons similar to those articulated earlier (Sec- 
tion 7.4 (page 38)), the implementation effort described 
above — which invokes data-regression technologies — is 
nontrivial and will necessarily require the involvement of ex- 
perts in the selected regression technology, especially in 
relation to step 3e of Process 4. 

11.7. Operational Use of Estimation Function 

Whether the estimation function is derived through a neu- 
ral net approach or another data-regression approach, the re- 
sulting tested and verified estimation-function implementa- 
tion would become a tool for operational use within a fielded 
system. The routine use of such a tool would involve the fol- 
lowing process: 

Process 5 (Operational Use of Estimation-Function 
Tool): 

Given: 

• G 111 * problem 

£ A, B £ 5, A 6 A(5), /estimation) 

created by running the subsystem that represents 
the implementation of the G #( algorithm and solves 
the given G^ problem (see implementation Pro- 
cess 4, steps 3(g)i through 3(g)v), which produces the 
implementation of an estimation function /estimation)- 

• a problem scenario 7 £ 5. 

Perform the following steps: 

1. Compute the characterization c = X(6, 7 ). 

2. Run the module that creates an implementation of a G- 
algorithm (see Process 2 (page 58)), resulting in an im- 
plementation of 

g = (5, 7 , V, T, a, f T , /tot, f m , /c, tt) £ G. 

3. Capture the estimation function output 

r = /estimation (c) 

(the estimate of the optimal choice of the values of the 
Type-G problem’s internal parameters for the problem 
scenario 7 ). 

4. Configure the Type-G problem g, replacing a with e: 

<?opt = (^) T> v t T t e > /r> /test) /m) /c> Tr) G 
G scenario ( A 7 ) • 

p op t is the optimal Type-G problem for solving problem 
scenario 7 . 
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5. Initiate a run of Algorithm 4 (the module developed in 
step 2 of Process 2) against the implementation of g 0 pt 
and capture output upon termination of ran. The output 
is an optimal solution for the given problem scenario 7 
(see remarks in Section 2.4.7 on page 13 concerning the 
concept of “optimum”). 

11.8. Which Data-Regression Algorithm? 

Interesting (but not necessarily academic) future work would, 
for some selected problem domain, consist of deriving an 
optimal-parameters-estimation function using different data- 
regression technologies and comparing their execution per- 
formance. The comparison would be more meaningful and 
reliable if it were based on the same computing resources 
and the same training/test data (i.e., the same precomputed 
data cases (see definition of the function D (Definition 149), 
which specifies the set of all possible precomputed data sets 
for a given G * 11 problem)). 

11.9. Final Remarks 

This appendix has described a generalization of the methods 
and algorithms that were specified in the main body of this 
paper, which targeted a specific problem domain (the space- 
data communications scheduling problem). These general- 
ized methods and algorithms are applicable to any problem 
in the very large class of real-world problems that are rep- 
resented by problem domains of Type G (see Definition 128 
(page 46) and Subsection 11.1.3). The specifications of the 
generalized methods and algorithms are sufficiently rigorous 
and complete to support their implementation (as described 
in Section 11.6 (page 57)) as a fielded system that efficiently 
produces an optimal solution for any problem scenario in any 
target problem domain of Type G. 

The G # problem £ € G* (see Definition 142 (page 52)), 
i.e., the problem of optimizing the Type-G problems and 
Type-G meta problems themselves, was incorporated into the 
G 1 * 1 * problem (i.e., the problem of devising an estimation func- 
tion by which to obtain, for an arbitrary problem scenario, 
an estimate of the optimal choice of the values of the in- 
ternal parameters of the Type-G problem g — it being noted 
that Algorithm 4 (page 49) applied to the Type-G problem g 
solves (i.e., produces an optimal solution for) the given prob- 
lem scenario). For reasons explained in Paragraph 11.5.1.3 
(page 54), the G* -problem optimization algorithm will be 
applied by executing Algorithm 4 against the Type-G meta 
problem £ 1 , resulting in an optimized version of the Type-G 
problem £0 = g. The methods and algorithms for solving a 
G #tt problem (8 e A, B C 6, A € A(8), /estimation) (see Def- 
inition 150 (page 56)) invoked data-regression technologies 
(artificial neural networks, support vector machines, evolu- 


tionary search, etc.) as a means to fit a model (a hypersur- 
face) to a set of known data points precomputed using the G 1 * 
method and algorithm, and thereby to derive the estimation 
function /estimation- With adequate computing resources and 
expert talent, these overall optimization approaches, as spec- 
ified, can be implemented as a fielded system that performs 
with maximum feasible efficiency solving any problem sce- 
nario in any target problem domain of Type G. 
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1, 19, see potential interference interval 
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M, 19, see mission event 
M*, 19, see mission event type 
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P, 1 8, see POCC operation period, see POCC 
Pmax, 22 

Q n , 17 

P 0 , 20, see user requirement 
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Ustaips, 49 

17 , see function 
Y, 20, see service 
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A, 46 
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r, 34, 46 
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$o, 20, see priority 


0, 23, see schedule, 46 
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® scenario, 46 

T, 56 
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o, 17, see function composition 
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skip FILL ®*, 23 
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swappeionr, 30 
swappeionu, 30 
swappei, 30 
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violations MINSEP *, 24 
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violations SA , 27 
violations SKIP *, 23 
violations 81 ® 1 ™ 111 *, 23 
violations SN ENDPTS , 26 
violations SN , 26 
violations STATION ' SA ' ENDPTS , 26 
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| • |, 16, see cardinality 
p, 17, see power set 
+ , 17, see interval endpoint 
~, 17, see interval endpoint 


-‘regr 
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/estimation, 55 57,61 

/g-execute, 49 

0, 16, see empty set 


algorithm, 6 

cardinality, 16, see | • | 

Cartesian product, 16 
characterization function, see A 
codomain, 17 

communications event window, 20, 21 
communications view period, 19, see V 


constraints 

GN Forward and Return, 25, see k gn 
SN Forward and Return, 25, see k sn 
S pace Network resource usage, 25, see k sn 
crossover, 11, 48 

data regression, 37, 56 
domain, 17 

empty set, 16, see 0 

evolutionary algorithms, 1 1 

evolutionary search, 13, 45, 47, 50, 53, 55, 56 

fitness, 28, 33, 35 

S* problem, 35, see fitness* 

Type-G problem, 47 
function, 16, 17, see X Y 

composition, 17, see o, 51 

G, 48, see Type-G problem 
G* problem, 52 

optimization, 52 
G** problem, 57 
algorithm, 57 
regression, 57 
G-algorithm, 49, 51 
genetic algorithm, 1 1 , 47, 50 

hypersurface, 55 

index, 17 

sequence, 17 
tuple, 17 

interference instance, 25, see interf* 
internal parameters, 7, 12, 13, 32-34, 36-38, 40, 42, 45, 50, 
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estimation, 36, see S** Problem, 54, see G** Problem 
estimation function, 7, 37, 38, 40, 50, 53-55, 61 
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endpoint 
+,17 
“,17 
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law of diminishing returns, 42 
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meta problem, 50 

meta-problem scenario, 51, see meta 
method, 6 

mission event, 19, see M 
mission event type, 19, see M* 
model, 56 
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user requirement, 16, 20, see Rq 

optimal, 6, 7, 11, 13, 32, 34, 37 satisfaction, 28, see satisfied* 
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POCC operation period, 18, see P, 22 
potential interference interval, 16, 19, see I 
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priority, 16, 20, see 4>o 
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problem domain of Type G, 46, see A 
problem scenario, 46, see F 
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process, 6 

prototype event, 20, see C 
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random number, 14 
recursion, 52 
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scheduling objective, 23 
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